A Java kernel

[Combuster]

After today's offline OSdev meeting, I decided I should just go and finish up the Java Primer page instead of letting it lay around collecting dust. In part I intend to cover a certain gap in the wiki content and give people a keyword to search for, but also in an attempt to further the compiler development cause a bit as well since the two are inherently intertwined here.

Since I built the whole thing from scratch, everything will be dead obvious for me personally, but things will probably be very different for everyone that haven't quite touched on the subject. I didn't plan on making it too easy and purposefully slapped a difficulty 3/4 rating on top of it, but there will probably be some things that need more coverage or got lost in sloppy prose. Please give it a whirl and make changes where you consider them useful, or drop me a note and I'll try to fill in the blanks.

[embryo2]

After today's offline OSdev meeting, I decided I should just go and finish up the Java Primer page

It's interesting how the meeting has changed your mind. Can you explain why?

About the page.

The article looks good. I see there some planning and careful attention to many details. So, it's quality is good.

It's nice to see a C-bound developer view of the Java in the wild. Such a view can help to attract some C developers to the new areas of OS development.

But what manages this "OS"? What resources or services that traditional OSes manage? Shouldn't it be called a Java bytecode to assembly translator partially written in Java with a lot of work made by a standard for many C developers tool-chain? However, Java to bytecode and bytecode to assembly parts are Java based if we pay attention to the usage of javac as the Java to bytecode part. Other parts (assembler, linker, image builder, bootloader) are borrowed from the C world. For those who isn't used to the low level C-style tools it's a drawback. And of course, for C developers it's a bonus to the simplicity of understanding the whole picture. But from the other side C developers can look at it too skeptically because there are so familiar tools with just some flavor of Java, so why to be bothered with this flavor (almost useless in it's current form)?

At least I'm glad to see some interest in Java and alternative environments for OS development. Also the attention to the details was somewhat profitable (in terms of learning) to me.

[Combuster]

There are many steps to this process. I deliberately went the way of the software engineer and reused as much as possible (javac, objectweb, yasm, binutils, grub, mkisofs) so that I could highlight the fundamentals of dealing with very high level languges as compared to drowning what I consider the important part of the article in all the support mechanics.

Shouldn't it be called a Java bytecode to assembly translator partially written in Java

"partially"? The compiler stage is 100% Java, thank you. I am sorry though for not sufficiently advertising your personal religious views on Java.

[Ycep]

Java is designed to work in its own virtual machine, not as normal executables...
Btw why would somebody want to have Java/C#/VB kernel? It is such a terrible idea, as they are beginner programming languages.
Through there is one famous person who uses C# on this forum, but I think that that person is very weird.

[iansjack]

Btw why would somebody want to have Java/C#/VB kernel? It is such a terrible idea, as they are beginner programming languages.

Even a half-decent beginner programmer wouldn't make such a silly statement.

[alexfru]

Java is designed to work in its own virtual machine, not as normal executables...

Take a look at Android and its ART. Java apps get compiled into executables (ELFs!) that contain machine code and bytecode and are dynamically linked to a set of libraries, which include the runtime (GC, interpreter/compiler/JIT/whatever) and various libraries (standard Java libraries, bits of the standard C library and custom libraries coming with the app). There isn't much abnormal about these executables. With all the recent improvements in the compiler (the one that compiles bytecode to machine code ahead of time or just in time) and in the runtime you get pretty decent performance. While you can't get rid of all of the overhead designed into the language, it doesn't mean you can't or shouldn't reduce it by the means available and that includes compilation into machine code and doing some of the same optimizations that modern C/C++ compilers do.

Btw why would somebody want to have Java/C#/VB kernel? It is such a terrible idea, as they are beginner programming languages.

Beginner-friendly ≠ unconditionally bad.

[onlyonemac]

Java and C# are not beginner languages; they're some of the most advanced and powerful programming languages out there. (Visual Basic is more of a "beginner" language as far as object-oriented languages go.) However this doesn't make them the most suitable languages for OS development, because most of their power comes from their high-level interpreted implementations, which for OS development is going to necessitate either running most of the operating system in an interpreter (with obvious performance penalties) or producing machine-code binaries from Java or C# code which, while theoretically possible, is not something that these languages are designed for and one would be left with pretty much no existing resources if one decided to do this. (Yes, I know Java and C# are actually compiled to a bytecode, but this bytecode still relies on an interpreter to execute it.)

[Ycep]

I frequently do the equation:

high-level programming language = easy and beginner programming language

[onlyonemac]

I frequently do the equation:

high-level programming language = easy and beginner programming language

Which is not always true. Stop doing [sic] that equation. Java is by no means a beginner language or a particularly easy language - it is in fact a very advanced language - but it's also a very high-level language.

[max]

[…] one would be left with pretty much no existing resources if one decided to do this […]

There actually are a few compiler projects that translate Java to native machine code. GCC's GCJ can for example compile Java either to bytecode, or to native code.

To the topic, when writing the earliest version of my kernel, I also planned a Java OS. I compiled the virtual machine directly into the kernel and it already work reasonably well. At some point I got interested in native executables and wasn't really happy with the performance (the JVM I ported had no JIT). But I still like the idea of a pure Java system, it would be really great. Just imagine having an OSGi container running into which you can deploy your driver bundles. Awesome.

The biggest obstacle I have encountered during this is getting a Java standard library for your system. The Java standard lib is very very big, and there are some implementations; I tried to get the OpenJDK one (which is actually the same as the one in the normal JDK) ported, but there is a big amount of native bindings that it expects and back in the day I just didn't have enough kernel functionality.

I would do it like this: Write a small C kernel that provides everything for the JVM; port a JVM that implements just-in-time-compilation; port or create a standard library. Then build an OSGi container on top of it and voila, a great base for a good system.

Now I'm quite tempted to realize this stuff...

[onlyonemac]

[…] one would be left with pretty much no existing resources if one decided to do this […]

There actually are a few compiler projects that translate Java to native machine code. GCC's GCJ can for example compile Java either to bytecode, or to native code.

I am aware of GCJ. It hasn't been updated in quite a while, and requires porting libgcj. Nevertheless it is an interesting project.

The thing is, I think a Java-based operating system would be very interesting from a security/isolation perspective; in some ways it's unfortunate that there's no way to easily compile Java code to run natively (although I wonder if compiled Java would offer the same security benefits anyway, since part of the security of Java comes from having everything "supervised" by the JVM).

[Schol-R-LEA]

(Yes, I know Java and C# are actually compiled to a bytecode, but this bytecode still relies on an interpreter to execute it.)

In modern Java systems at least (and CLI languages as well, AFAIK, but I am not certain), the bytecode is mainly used to provide a degree of portability (i.e., it isn't tied to a specific hardware platform) and security (because it ensures that the code has been vetted by the JVM), not for direct interpretation. While the pseudo-machine interpreter is still available, for most Java programs today, some or all of the program is actually compiled to native code when the JVM interpreter is invoked, and the interpreter will (I think) cache the results of this for subsequent program invocations.

In effect, JVM bytecode as it is now used is less an executable format and more an intermediate representation for a compilation process that has been arrested partway through the process. There are some things which generally still use the JVM interpreter because they require on-the-fly code generation (e.g., most of the Reflection tools), but the JVM interpreter/JIT compiler combination merges the native and interpreted code fairly seamlessly.

[Schol-R-LEA]

I frequently do the equation:

high-level programming language = easy and beginner programming language

Not to sound like a broken record on this subject, but... have you ever studied languages such as Clojure, Smalltalk, Scala, Prolog, or Erlang? I assure you, those are not limited in the way you seem to be thinking. Some of them are limited in other ways, perhaps (Prolog in particular comes to mind), but trust me, they are far more advanced, and far more expressive, than C or even C++ could ever dream of being.

Or to put it another way: do you think that SQL is for beginners? I may have my issues with it being a rather broken implementation of relational algebra, but as a language it is highly declarative and quite powerful, despite not having many things most programmers consider necessary parts of a full language (such as explicit loop constructs). It is a domain-specific language, and really not any use for anything other that querying a database, but in its domain it is quite powerful (though it could be far more powerful still if it were designed better... no, damn it, I am not going to let myself get into that here, I've written that rant enough times elsewhere (NSFW language in the thread, so be careful) and don't need to repeat it).

[matt11235]

Just imagine having an OSGi container running into which you can deploy your driver bundles. Awesome.

I think Eclipse have a lightweight Linux distro with their own OSGi server for Raspberry Pis.

[Ycep]

You know, machine code could be powerful.
Brainfuck could be too.

Also I forgot to say :
Easy could be powerful.