100% Java OS

[embryo]

Here www.jembryos.org is new OS description. If somebody is interested in architectural features or it's business applications we can discuss it here.

[VolTeK]

Ill be honest, i wasn't expecting this to be legit. Good job, and Good luck.

[embryo]

Ill be honest, i wasn't expecting this to be legit

Sorry for my english, but what the 'legit' means ? Why it should be illegal ?

[Combuster]

"legit" is a shorthand for legitimate, as in, not a fake, cheated, or otherwise misleading. For instance, Android appears to be Java because that's what the developers get to see, but the majority of the OS functionality is actually written in C and C++. Similarly, most people claiming to have a Java OS actually have a C(++) kernel running a JVM, or don't even know what they are doing.

Sorry for my english

The opposite of "illegal" is "legal", which has to do with laws and rules. Also, there's never a space in front of periods, commas, question marks and exclamations - that reads like you've had cheap Asian schooling. Enabling and listening to your browser spell checker also helps a lot

[embryo]

most people claiming to have a Java OS actually have a C(++) kernel running a JVM

It is not the case for my system.

there's never a space in front of periods, commas, question marks and exclamations

Ok, I'll pay respect to your explanation.

[Bender]

Hi,
Seems like a good project.
Apologies for showing profound ignorance here.
I haven't seen the sources and neither I have tried it but I am curious to know about how did you manage to use Java as a programming language for such low level tasks. Did you write a bytecode translator that translates Java Bytecode to x86?
Or a kernel level Java Interpreter? Or your own compiler?
-Bender

[Antti]

I am quite impressed with the amount of work you have done. I do not know enough about details so that I could give you any feedback yet. I will check your project because it seems that there might be something interesting. At least I wish you good luck.

[Pancakes]

I read a good bit of you documentation. It was a lot to read, but I like how you have really tried to plan it all out.

It should be absolutely possible to write the drivers in Java too especially if you translate the byte code into machine instructions, and drop out any special checks like array length checks (but for like slower or normal Java code leave them in). You might even use some tricks like special objects where the method calls directly translate into direct memory writes, I/O port read/writes, and such. You know like CPU.IOWrite where IOWrite is a static method, or CPU.WriteMemory32. You know there is a difference between different achitectures like X86 and ARM so you just have to have specific methods for those to handle those cases. Some of your kernel would have to be in assembly though like you said. But, the actual methods do not really exist and are just place holders. Have to create a JAR with them just for people who write using an IDE so auto-complete will work but that is it.

I am curious are you going to write the java compiler/translator in assembly?

I have written a fairly large Java interpreter, http://code.google.com/p/rhino-java-virtual-machine/, and I have to say even that was a fair amount of work. It only interpreted the byte code because I was learning as I went along so writing something to translate into machine code would really add another layer of complexity and challenge. But, you can do it!

[embryo]

I am curious to know about how did you manage to use Java as a programming language for such low level tasks. Did you write a bytecode translator that translates Java Bytecode to x86?

Yes, there is a one to one translation of bytecodes into the machine representation. The translation takes compiled Java class (bytecodes and class definition) and generates machine code.

[embryo]

I will check your project because it seems that there might be something interesting.

It's a good idea

At least I wish you good luck.

Thanks

[embryo]

It should be absolutely possible to write the drivers in Java too

Of course. And there already are drivers, but not so much - just the ps2 keyboard and text screen.

But maybe you mean to write drivers for other systems? It is possible using Java Assembler or plain Java. But currently the efficiency of machine code based on the plain Java is not astonishing. There is a need for good compiler. The currently existing one is simplistic and has almost no optimization capabilities.

You might even use some tricks like special objects where the method calls directly translate into direct memory writes, I/O port read/writes, and such.

The I/O space access is actually done as a set of special methods.

You know there is a difference between different achitectures like X86 and ARM so you just have to have specific methods for those to handle those cases.

Currently only x86 instructions are supported. To support ARM or another processor there should be some means to translate bytecodes into ARM machine code representation. Now it is relatively straightforward to write such representation by a way of simple copying of the existing solution for x86.

Some of your kernel would have to be in assembly though like you said

It is still Java, not assembly. But the part, responsible for machine code generation, looks like assembly when actually it is a Java code. And the look and feel can be changed if there will be a need for it, but an assembly look and feel seems more convenient.

Have to create a JAR with them just for people who write using an IDE so auto-complete will work but that is it.

There is such project in the downloadable part of the jEmbryoS. Of course, it is possible to copy classes from the bin directory into a jar and to use it separately. But the project is better than the jar only, that's why there is a project.

I am curious are you going to write the java compiler/translator in assembly?

The translator is already there. There are two levels of it - the Java Assembler and one to one bytecode translators. The second is implemented with the help of the first.

I have written a fairly large Java interpreter, http://code.google.com/p/rhino-java-virtual-machine/

I have looked at it quickly, but it is in C. My experience with the C environment is almost non existent and I have no tools for C code to be compiled or browsed with some help (like Java IDEs can do).

But your goal is not clear. If you wish to create a JVM then how you can state the goal of a very small package? There are 144 bytecodes and beside of them you need some means of loading and interpreting the bytecodes. Also there should be some means for the bytecode's job became visible. And having such minimal implementation how do you think it should be used? How it should interact with the world? There are many questions.

I went along so writing something to translate into machine code would really add another layer of complexity and challenge

In fact it is more simple to write a translator than a complete interpreter. The translator just produces some bytes while the interpreter also runs the bytes (from bytecode). Just writing to the disk is a simple task, but to run something on the processor is a more complex task because of the running system should produce something useful while the translated code is just a bunch of bytes and the usefulness of it is achieved by another system.

[GhostlyDeath]

Your OS has licensing issues:

• Your OS is GPLv3+
• GNU Classpath is GPLv2+
• Oracle's Classpath is GPLv2

You must either:

• Upgrade GNU Classpath to GPLv3+ and drop Oracle's Classpath.
• Downgrade your GPLv3+ to GPLv2+

----------------------------------

On other notes, VERY critical points:

Where are all the comments? You do not even have a single JavaDoc element in any of your source files. From reading your gigantic paper you expect others to assist you, but if you leave no comment not even a hint, how do you expect that? JavaDoc elements are also extremely helpful in knowing what classes, methods, fields, and annotations do.

Code: Select all

public class Translator extends EmbryoConstants implements CompilerConstants

That class virtually only contains static methods! Where did the OOP go?

./jEmbryoCompiler/src/org/jembryos/compiler/x86/translators

That directory contains 144 files for every single byte code instruction, and on top of that all of those all contain static methods!

Code: Select all

write_arrayNullPointerAndIndexCheck_dataAddressEDX_arrayIndexEBX

That is a very nice and far TOO descriptive name of a method and consists of far too many characters.

jEmbryoService/src/org/jembryos/service/driver/Ps2KeyboardDriver.java

For all your isWhateverOn() methods, you can replace that ALL with a simple Enum and use an EnumSet.

jEmbryoAssembler/src/org/jembryos/assembler/

Your assembler is overly complex and splayed into 89 class files mostly consisting of individual instructions in their own class files.

In reality, your byte code recompiler should take logic in and output logic, it appears that you may eventually plan to add support for other architectures. Rather than implement every bit of an assembler, it would be much simpler to output instructions using abstract logic. If not, at least use some kind of table rather than 10,000 methods for every single variant of every single instruction.

jEmbryoApp jEmbryoClassFile jEmbryoCore jEmbryoFAT jEmbryoS
jEmbryoAssembler jEmbryoClassModel jEmbryoDebug jEmbryoHelperAPI jEmbryoService
jEmbryoBootstrap jEmbryoCompiler jEmbryoDocs jEmbryoJavaAPI jEmbryoTest

Too many directories, especially since they all contain /src/org/jembryos in them anyway. If you read the javac manpage along with the java manpage, you would see there is such as an option such as -bootclasspath?

JNode, SUN Classpath, GNU Classpath.

It appears that you fail to mention that you even include these, one has to look at the source code to determine this. You must also specify the licenses of those projects and make sure that they are compatible with your own.

Seeing that none of your code is commented in any fashion, and bumping into code that actually is commented such as in jEmbryoAssembler/src/org/jembryos/assembler/x86/AssemblerProgram.java, puts serious doubt on whether or not you've written said code.

-------------

In short: It seems clear that you lack programming experience, you really need to reconsider these basic points. Your code is complete garbage. The code is an unmaintainable mess.

You want businesses to use your operating system, but your mess has one problem. The only person who could ever work on your OS reliably is yourself and if you die or lose interest then the OS is dead and unsupportable. That is too risky for a business.

If you spent your time actually writing good, readable and reasonable code instead of writing over readable design documents and forum comments, your OS would fare much better.

[bwat]

In short: It seems clear that you lack programming experience, you really need to reconsider these basic points. Your code is complete garbage. The code is an unmaintainable mess.

Wow! That was a bit harsh especially for someone who hasn't offered up any of his own code to be placed under scrutiny. I'm going to have a guess that you're not so perfect yourself.

[embryo]

Your OS has licensing issues:

• Your OS is GPLv3+
• GNU Classpath is GPLv2+
• Oracle's Classpath is GPLv2

You must either:

• Upgrade GNU Classpath to GPLv3+ and drop Oracle's Classpath.
• Downgrade your GPLv3+ to GPLv2+

Yes, there is the unnoticed license incompatibility issue. But actually the problem is related to the Sun's (now Oracle's) code. The GNU Classpath allows to use later versions of GPL. However the issue should be resolved and your notice is useful. Thanks for the point.

Where are all the comments?

The comments are in the source code. If you have not noticed them it only means that not every source file has comments. The commenting process is ongoing and the situation should be improved some day.

JavaDoc elements are also extremely helpful in knowing what classes, methods, fields, and annotations do.

There's no JavaDocs generated yet because of incomplete source code commenting.

That class virtually only contains static methods! Where did the OOP go?

Do you want OOP purity or working system? If you still do not know the pattern of extending an interface with constants for using them without full interface name inserted then it is better to pay attention to such pattern advantages.

That directory contains 144 files for every single byte code instruction, and on top of that all of those all contain static methods!

And what's the problem? If it is only about your aesthetic feelings then may be it is not the best place to write about your irritation?

Code: Select all

write_arrayNullPointerAndIndexCheck_dataAddressEDX_arrayIndexEBX

That is a very nice and far TOO descriptive name of a method and consists of far too many characters.

Yes, the name is long, but it is descriptive. If you can use any IDE that is a bit better than a text editor then just press point button after class name and select method name from the list - in such a way you can save efforts for typing method name.

For all your isWhateverOn() methods, you can replace that ALL with a simple Enum and use an EnumSet.

There are many variants we can do some things. And your personal choice is not the best. And insisting on it is something not very nice.

In reality, your byte code recompiler should take logic in and output logic, it appears that you may eventually plan to add support for other architectures. Rather than implement every bit of an assembler, it would be much simpler to output instructions using abstract logic. If not, at least use some kind of table rather than 10,000 methods for every single variant of every single instruction.

As described in the "so long" documentation the goal was to emulate assembler in Java. If you consider this goal then you should understand that your solution is just not working.

Too many directories, especially since they all contain /src/org/jembryos in them anyway.

It's just modularity. You can read about the profit it can bring to you.

If you read the javac manpage along with the java manpage, you would see there is such as an option such as -bootclasspath?

It seems you are trying to compile the project under Linux using text interface only. It is interesting idea, but the modern IDE is much better way to write big programs. Of course, your habit is always for your service, but please consider to try any free IDE and there will be no problems with options and long method names.

JNode, SUN Classpath, GNU Classpath.

It appears that you fail to mention that you even include these, one has to look at the source code to determine this.

The inclusion is described in the documentation.

Seeing that none of your code is commented in any fashion, and bumping into code that actually is commented such as in jEmbryoAssembler/src/org/jembryos/assembler/x86/AssemblerProgram.java, puts serious doubt on whether or not you've written said code.

It seems nobody in the world can tell the difference between a person's code and the code you can think is not written by the person. So you can claim your right on every open source project, because all the files there are at least a bit different. It's a very nice claim!

In short: It seems clear that you lack programming experience, you really need to reconsider these basic points. Your code is complete garbage. The code is an unmaintainable mess.

At least some useful points about licensing is appreciated, but everything else is just your irritation, I suppose.

You want businesses to use your operating system, but your mess has one problem. The only person who could ever work on your OS reliably is yourself and if you die or lose interest then the OS is dead and unsupportable. That is too risky for a business.

Please, let the business decide what is risky and what is not.

If you spent your time actually writing good, readable and reasonable code instead of writing over readable design documents and forum comments, your OS would fare much better.

Good, readable and reasonable code is a very fuzzy definition. But you always can insist on it in order to throw your irritation on somebody else, it even works sometime.

[GhostlyDeath]

The comments are in the source code. If you have not noticed them it only means that not every source file has comments. The commenting process is ongoing and the situation should be improved some day.

There's no JavaDocs generated yet because of incomplete source code commenting

It is very important to comment your code as you write it, at least a description of what each method does, what the purpose of a class is, why a field exists.

You can include JavaDoc comments even before your code is even compilable (the code must be able to be compiled for HTML documentation to actually be generated). Then once your code does compile or is mature enough you can just run javadoc on it.

It seems nobody in the world can tell the difference between a person's code and the code you can think is not written by the person. So you can claim your right on every open source project, because all the files there are at least a bit different. It's a very nice claim!

The reason I raised such point is the extreme lack of comments everywhere, then all the sudden comments. After glancing over the source files you eventually see that there are virtually no comments, then once some commented things start to appear out of nowhere, there is a stylistic clash.

It's just modularity. You can read about the profit it can bring to you.

Java has the notion of packages, similar to namespaces in C++. Rather than having a directory tree of:

Code: Select all

foo/bar/assembler
foo/bar/compiler
foo/bar/bootloader

You instead have:

Code: Select all

FooBarAssembler/src/foo/bar/assembler
FooBarCompiler/src/foo/bar/compiler
FooBarBootLoader/src/foo/bar/bootloader

Modularization is fine but having 12 directories (which will soon turn into 20+ directories) may become less maintainable. Although you seem to be using Eclipse with tons of different projects separate than combined.

And each package can have a file called package-info.java which describes the actual package. So that way when you generate the JavaDoc you know what the purpose of a package is.

Unified directories also helps on having a single class path rather than it being specified multiple times.

Yes, the name is long, but it is descriptive. If you can use any IDE that is a bit better than a text editor then just press point button after class name and select method name from the list - in such a way you can save efforts for typing method name.

Using an IDE, long names do not seem to be that of a problem. But with extremely long names, it takes up more space on the screen, in memory, and on the disk. Also as per memory, Java uses UTF-16 strings so "write_arrayNullPointerAndIndexCheck_dataAddressEDX_arrayIndexEBX" which is 65 characters will end up taking up 130 bytes instead. Any meaningful stack traces on say an 80x25 terminal will be word wrapped. It may be better to just use annotations or JavaDoc to convey the information rather than putting it in the name itself. And I am pretty sure Eclipse understands JavaDoc and will show what it says when you start typing a method or a field.

As described in the "so long" documentation the goal was to emulate assembler in Java. If you consider this goal then you should understand that your solution is just not working.

Personally, I would just replace the "ldc #?; ldc #?; invokestatic (Ljava/lang/String;Ljava/lang/String;)V foo/bar/Assembly.asm" with inline assembly (provided the target is the kernel and not a program the user would run otherwise that would be a major security flaw).

Said static method would be:

Code: Select all

package foo.bar;

/**
 * This is a special class which contains a static method for encoding assembly
 * instructions for use in the recompiler pass.
 */
public final class Assembly
{
	/**
	 * Encodes an assembly instruction from the specified string.
	 *
	 * @param is The target instruction set to use for the statement.
	 * @param whatever Whatever assembly statement you want to encode.
	 * @see InstructionSet
	 */
	@AOTSpecialMethod
	public static void asm(String is, String whatever)
	{
		throw new Error("This is an AOT special method, it cannot be invoked.");
	}
}

Please, let the business decide what is risky and what is not.

Fair enough.