Среда разработки Java это только компилятор коммандной строки? Нет, это только лишь очередной миф и возникает он известно отккуда. Когда очередной новичек просит у своих более опытных коллег: "Дайте мне компилятор Java!" Ему в большинстве случаев отвечают: "javac.exe в директории JDK". И это будет правильно, поскольку в каждым пакетом разработчика поставляются не только основные классы, документация и виртуальная машина для запуска программ, но еще и сам компилятор с языка Java в байт-коды виртуальной машины Java. Этот компилятор коммандной строки способен выполнить практически все требования которые может предъявить к компилятору проограммист. Но наскольку мы уже знаем, Java достаточно богатая среда по возможностям и обойтись одним лишь компилятором при этом жостаточно тяжело. Да, несомненно, что вполне можно развивать и поддерживать достаточно крупные проекты при помощи простейшего текстового редактора и компилятора поставляемого с JDK. Обычно для большей гибкости управления сборкой используют так же и различные менеджеры сборки и препроцессоры, например, к их числу можно отнести Ant и SubJava . Такая техника работы достаточно проста и ообычно не приносит видимых затрат на дополнительное программное обеспечение. Однако современное искуство программирования зачастую связано с использованием так называемых интегрированных средств разработки (IDE), которые сочетают в себе и текстовые редакторы и компиляторы. Кроме того в последнее время получили широкое распространение визуальные построители, при их помощии можно построить не только визуальную часть интерфейса пользователя, но и определить бизнес-логику приложения. Такая совокупность средств разработки уже тянет на настоящий пакет быстрой разработки приложений (RAD). Если ко всем этим преимуществам добавить еще и большие возможности по повторному использованию программных компонентов, предаставляемыми Java, то в некоторых случаях вообще возможно программирование без программирования. Все, что Вам нужно, это визуально определить программные компоненты, визуально установить между ними связи и полноценное приложение готово. Естественно, что в таком случае, будет весьма посредственный программный продукт, но все же это еще один шаг в этом направлении. Причем шаг достаточно весомый. Недостатком работы с коммандой строкой можно смело назвать еще и проблемы возникающие при проектировании сложных интерфейсов пользователя. Не секрет, что в языке Java имеется достаточно большое количество так называемых менеджеров расположения элементов интерфейса. При всех их богатых возможнастях полноценное их использования даже опытными программистами затруднено. Как же быть в таком случае? Выход есть - визуальные редакторы интерфейса. Причем в большинстве сред разработки программист будет видеть именно то, что увидит в последствии пользователь. Все элементы будут отображаться так же, как и в режиме выполнения программы. Т.е. другими словами, среда разработки выполняет графический интерфейс пользователя во время его построения. Именно выполняет, поскольку каждый элемент интерфейса это отдельный объект, со всемы вытекающими из этого последствиями. Некоторые могут возразить, мол мы не работаем с графическим интерфейсом, поэтому на не нужно никаких визуальных построителей. Да действительно, если не нужен графический интерфейс (например, это серверное приложение - сервлет), то зачем использовать громоздкий инструемнт? Но не стоит забывать о повторном использовании кода, в Java он реализуется посредством JavaBeans. При этом все связи можно установить между этими программными компонентами именно визуально. Значительно выиграв по времени и совершив меньше ошибок. Ведь проще разобраться с несколькими пиктограммами представленными на одном экране и связями между ними, чем в сотнях строк исходного кода. В настоящее время основной критерий создания программных продуктов, это время их разработки, чем оно меньше, тем лучше. Причем простым увеличением количества разработчиков время разработки может не только не уменьшиться, но и увеличиться. Для минимизации такого эффекта разработаны даже специальные методы, к примеру "Операционная бригада", предложенная Г. Бучем, где только один человек программирует, а в десятеро больше ему ассестируют. Пожалуй именно таким способом и придется поступать если не использовать специальные механизмы групповой разработки. В наиболее мощных IDE такие механизмы реализованы, а в некоторых имеется возможность использовать технологии сторонних производителей. Но все же, интегрированная поддержка групповой разработки лучше, чем от стороннего производителя. Хотя у последней есть и свои преимущества. Использование этих нехнологий позволяет использовать бодьше программистов в одном проекте, без значительного снижения эффективности их деятельности. Если сформулировать механизмы работы большинства таких систем, то в них имеется общее хранилище исходных кодов, каждый программист работает отдельно со совим кодом, для других программистов доступны только законченные версии. При этом обычно создается несколько редакций одной версии, что позволяет в случае необходимости вернуться к предыдущей редакции или даже версии. К тому же так называемая самодокументация кода, когда программист пишет документацию прямо в исходном коде, позволяет еще больше сократить время разработки. Наиболее популярными средами разработки такого класса являются JBuilder (http://www.inprise.com/) и Visual Age for Java (http://www.ibm.com/). Причем в последней используются еще и такие приемы, как отказ от хранения данных в файловой системе с разбиением на каталоги согласно пакетам, а так же компиляция "на лету", при этом, если изменен только один метод из класса, то перекомпилируется при сохранении не весь класс целиком, а только измененный метод. Использования в качестве хранилища единой базы данных, а не структуры каталогов может избавить от ограничений операционной системы на общую длинну имени файла, включая каталог, а выборочная компиляция избавляет от внесения неочевидных ошибок, ведь все ошибки отображаются сразу же при сохранении-компиляции. Несомненно, что все преимущества предоставляемые даже самой мощной из сред, с неимоверными возможностями, могут быть полностью перечеркнуты некачественным проектом программного продкута или неквалифицированными программистами. Кстати, для успешной проектировки больших и сложных проектов целесообразно использовать case средства. И такие средства для Java есть. Это Together (http://www.together.com/) и Rational Rose (http://www.rational.com/). При их помощи моожно создать модель будущего программного продукта, а затем экспортировать ее в среду разработки. Или же осуществить реверсивную инжинирию уже существующего проекта и разрабатывать его дальше в самом case средстве!
Другими словами, в Java не поддерживается модное в последнее время течение среди производителей сред для языков программирования - один язык - одна среда разработки - одна фирма производитель. Что словно бы цепью приковывает разработчика к продуктам одного производителя. Для Java же существует не одна среда и не две, не все они конечно обладают такими монстроидальными возмодностями, некоторые только обеспечивают подсветку синтаксиса и простейшие функции по подсказкам имен пакетов или методов.

Что же касается других языков для виртуальной машины Java, то с этим дела обстаят не так хорошо, как с самим языком Java. Они в основном или транслируют свои исходны коды в исходные коды понятные компилятору Java или компилируют обычным компилятором коммандной строки сразу в байт-код.

Таким образом миф о наличии единственного компилятора Java в виде программы коммандной строки не соответствует действительности.