Der Java-Compiler (javac) erzeugt aus der Javasource einen Bytecode, den jede VM versteht. Für jede .java-Datei entsteht (mindestens) eine .class-Datei. Erst zur Laufzeit findet das Binding statt, nämlich bei der Interpretation des Bytecodes durch die VM. Dadurch bekommt Objektorientierung Sinn und wird das Konzept von Reflection erst möglich.
Wieso bekommt Objektorientierung dadurch erst Sinn? C++ Programme laufen (in der Regel) auch nicht auf einer VM. Bedeutet das, dass bei C++ OO keinen Sinn macht?

Es gibt eine Spezifikation für die Java Sprache und eine für die Java Runtime Environment. Diese beiden Spezifikationen sind unabhängig voneinander, heißen aber trotzdem beide Java. Bei C# haben beide unterschiedliche Namen. Die Sprache heißt C# und die Runtime Environment heißt .Net.
Mir geht es hier nur um die Sprache. Die RTE komplett auf einen Atmel uC zu übertragen wäre schwierig.
Man verliert dann natürlich die Vorteile einer JAVA VM, das ist für mich aber kein Problem. Auf Threads muss ich allerdings nicht verzichten. Selbst Reflections könnte man auch ohne VM realiseren. Ob das auf einem uC Sinn macht ist eine andere Frage.

Zitat Zitat von pebisoft
da man mit java keine schnittstellenpins einzeln (seriell,parallel) programmieren darf ( ist das oberste gebot von java), ist es von vorne rein schon nicht durchführbar , wenn es java genannt werden soll.
Wie ich schon sagte sind Sprache und Runtime Environment zwei verschiedene unabhängige Dinge. Du beziehst dich auf die Java RTE, nicht auf die Sprache.