1) Насчет типов - вы 100% правы. Стандартные типы навроде int - могут зависеть от разрядностии процессора. Указатели - и подавно. Это документированная особенность. На х86 int вообще 32 бита бывает. Если на такие вещи не закладываться а писать код нормально, делать как советует Lampus, проблем не будет. Математика вообще без проблем с восьминогой тиньки на какой-нибудь ксеон перенесется.
2) Разумеется, специфика и компилера и платформы - зло. Если так выщло что оно неизбежное (например, низкоуровневая работа с периферией, специфичная для конкретного чипа и только него) - это логично вынести в отдельную четко очерченную сущность, с платформонезависимым интерфейсом для остального кода наружу. Чтобы потом иметь возможность без особого геморроя перейти на другую платформу/чип/что там еще. Отсюда же следует что не стоит увлекаться уникальными фичами конкретного чипа которых нет у остальных. Чтобы потом не было мучительно больно, если чип снимут с производства, а у остальных не окажется аналогов нужной фичи.
3) Вообще, по возможности не стоит не закладываться на endianess. Если данными надо меняться с внешним миром и при том в предсказуемом формате, который будут разгребать другие, лучше всего сделать универсальные врапперы, выдающие всегда правильные и предсказуемые форматы. Неплохой пример как это делать можно найти где-то в районе http://www.oberhumer.com/opensource/ucl/ - довольно портабельная либа сжатия данных, которая работает под массой платформ. С напрочь разными endianess, размерами указателей, integer'ов и что там еще. Потенциально можно немного проиграть в скорости, хотя современные компиляторы обычно допирают довольно хорошо заоптимизировать такие вещи.
4) +100500. Оно не обязано называться именно HAL, но суть именно та самая :)

KM, что ж, могу дать только один совет.
Вряд ли вы здесь найдёте людей реально применявших Java в Embedded (хотя это и не исключено).
Раз пока у вас не имеется живой железки на ARM-е, то используйте эмулятор. Возьмите qemu-arm, поставьте на неё минимальную установку Debian Linux и на неё уже ставьте jvm. Сможете хотя бы оценить как с этим работать и сколько оно жрёт памяти. Скорость работы, к сожалению, из-за эмуляции оценить не удастся, но хоть что-то. К тому же если ARM поддерживает технологию Jazzelle, то он может исполнять некоторую часть байткода прямо на процессоре (да хоть тот-же AT91SAM9260). Но такую фичу должна поддерживать и сама jvm.

P.S. Объясню почему у большинства здесь туго с явой. Просто если вдруг речь заходит о массовом производстве, то экономят не то что на памяти, а даже на конденсаторах. Но если всё же понадобилась большая страшная железяка с Linux, то последний предоставляет такое количество библиотек и переносимость что многим даже и не снилось, так что применение такого монстра как Java просто не нужно.

Цитата

К тому же если ARM поддерживает технологию Jazzelle, то он может исполнять некоторую часть байткода прямо на процессоре (да хоть тот-же AT91SAM9260). Но такую фичу должна поддерживать и сама jvm.

Вот что по этому поводу говорят
http://www.java.net/node/669600

Цитата

Sun can sell you a license for the Jazelle technology by ARM but it does cost money. You should first consider if you really need Jazelle support. In our experience Jazelle is only really beneficial in certain environments such as very limited memory availability and requirements for very short application start-up times. In most general cases the runtime optimizations (JIT, others) performed by the VM are sufficient or better than Jazelle.

Так что судя по всему Jazelle для явы - как мертвому припарки :)