Слышал можно Java код на gcc в Линуксе компилировать. Правда это?

Сущая правда - http://gcc.gnu.org/java/.
Может компилить исходники не только в байт-код, но и непосредственно в машинный код процессора и преобразовывать байт-код в машинный код.

А есть ли смысл? Ведь официальный компилятор бесплатен.

Компилить в машинный код клиентские приложения ещё как имеет, побыстрее работать будут

Не хочется тебя огорчать но это не совсем так. Виртуальные машины уже достаточно оптимизированы и компилирование в машинный код необходимо только в конкретных случаях.

вообще странное приложение получается.я по крайней мере не могу сказать, что там только машинные кода. можете попробывать потестить.
вообще берем простой класс и в нем делаем в каком-то методе Class.forName().

Предположем так...

Компилим с помощью gcj. (gcj --main=Start -o someName.exe Test.java ). получаем someName.exe

берем второй класс, например


Компилим это нашим javac, получаем TestLoad.class

в одной папке собираем TestLoad.class,someName.exe и dll, которые нужны (смотря чем компилить).

запускаем someName.exe и что получается ?

У меня на Windows + gcj 3.4.5 c mingw - "Hello world". Какой тут машинный код спрашивается?

Не знаю как GCJ, но Jet Excelsior поддерживает динамическую загрузку классов, и компиляцию их прям во время исполнения.
1. Попробуй запустить приложение на голой системе без JRE.
2. Попробуй вместо константы вставить туда скажем args[0].

На самом деле gcj в библиотеках содержит и байт-интерпретатор тоже (написанный Kresten Krab Thorup). Так что если вы используете Class.forName(), байт-интерпретатор будет прилинкован к вашей программе. Если не используете, ваша программа будет чистый машинный код.

Кстати, при использовании Class.forName ваш .exe файл сначала ищет .dll с подходящим именем, и только если не находит, то грузит .class файл и интерпретирует байт код.

Проблема gcj в том, что по языку она примерно на уровне jdk1.3. Новый фич нет.

Ну GUI в java, например, работает, мягко говоря, не очень быстро.

Тут даже не заню что сказать с одной стороны зависит от того как писать, но с другой стороны у самого осталась оссоциация java и медленного гуи. Может всетаки виноват свинг ? И неужели откомпилированная в машинный код программа начинает заметно быстрее работать с гуи ?

По моему опыту, нет.

гуй гую рознь. Тот же swt весьма шустро работает в явовских программах. По крайней мере визуально от сишных программ по скорости не отличить

Зато глючит, я например в одной SWT-шной программе регулярно наблюдаю десктоп сквозь главное окно.

И первое верно и второе верно. Java код работает очень шустро. Единственный недостаток - медленный ГУИ (но это только под виндой кстати). Думаю медленность ГУИ связана с кроссплатформенностью. Вон SWT например - летает. А на процессорах > 3 гигагерц и свинг летает

Вообще скорость ГУИ от байткод/нативный-код мало зависит. Те же самые вызовы АПИ. GCJ линкует сборщика мусора (при компиляции там тоже можно кое какие опции выставить), в остальном - тотже exe, что и с++.
По моему личному опыту по скорости что gcj скоппованная, что javac - проги не отличаются. Но на линуксе "нормальный" javac намного удобнее конечно из за кроссплатформенности.
Смысл gcj же вижу только для того, чтобы поиграть.
Добавлено @ 11:36
PS:
JAV исты зря в ГУИ полезли вообщето. ИМХО именно этим JAVA себе "славу" медленности заработала. Иначе возможно она была бы намного распространённее для консольных приложений, библиотек и что немаловажно - серверов. Потому что по всем параметрам кроме ГУЙ она перегоняет многие языки по скорости и удобству.

1) иногда удобно 1 выполняемый файл иметь. Без необходиомсти ставить jre
2) в gcj более тесная интеграция с всеми gcc-шными языками.
3) скорость скомпилированной программы сопоставимая с jre, но все-таки выше. В тех случаях когда это критично, имеет смысл рассмотреть альтернативу.