Сообщество Eclipse провело опрос о предпочтениях Java-разработчиков

Невнимателен - это да.Но читал сам. И то, и то читал, забыл про BSD в плане модификации. Про складирование не заикался даже. Про профит также.

опять же почитайте второй пункт определения открытого ПО.они обязаны предоставить сырцы.

Заказчикам. Если ты возьмешь проект на gpl, внесешь изменения, то ты обязан предоставить сорцы лишь тому, кому предоставил и бинарники, а как они поступят и с тем и с тем, то это уже их дело. Ты НЕ ОБЯЗАН возвращать код в апстрим.

> с выходом Java 6.0 поддерживается API для выполнения кода скриптовых языков.

И? Если Java научилась исполнять (интерпретировать) скриптовые языки, это повод мешать всё в кучу? Я, теоретически, могу на Perl(6) написать интерпретатор JS, но это не будет поводм мешать JS в кучу с Parrot. Этой связи [пока] нет. По той ссылке, что я привёл, ты конкретно пытался отмазаться, «намёками». И сейчас так же в кучу всё.

(Неужели ты думаешь, что я не отличаю JavaScript от Java? Зачем наводить тень на плетень.)

Посмотри на мой сайт, всё поймёшь, чем я занимался до 2006 года. Eclipse, кстати, попробовал впервые ещё в середине 2002 года, когда JBuilder 5.0/6.0 был уже для меня избыточен и тяжеловесен. Потом были метания между NetBeans 4.x-5.x и Eclipse. В итоге по удобствам разработки и минимуму «мусорного» кода в проектах выбрал Eclipse.

> Неужели ты думаешь, что я не отличаю JavaScript от Java?

Возможно, отличаешь ;) Но иногда ты крайне косноязычно, типа: «краткость — сестра таланта», «молчание — золото», «говори поменьше — сойдёшь за умного», — выражаешься. При этом твою «краткость» часто можно трактовать совсем не в пользу твоего интеллекта, когда мне, например, тема и так известна, чтобы ещё по «намёкам» пытаться догадаться то же ты имел в виду.

visualswing4eclipse

перешел на него с Netbeans, после того как затрахался бегать по менюшкам чтобы поправить что-то. И знаете, писать руками swing быстрее и удобнее чем мышевозить.

Это не опрос о предпочтениях Java-разработчиков, это опрос идиотов, использующих Eclipse

> visualswing4eclipse

This project is determined to produce a free, open-sourced and Netbeans-like GUI designer for the Eclipse IDE.

Догоним и перегоним NetBeans! :)

the latest version requires Eclipse 3.4 or Eclipse 3.4.1.

Как он с 3.5.x ? Ощущение, что его постигла та же судьба, что и VE.

>приложений для домашних компьютеров.

Да как же писать для десктопов, если жаба тормозит больше, чем черепаха?

Говорю как жабакодер.

>>69.5% разработчиков используют Eclipse для программирования на языке Java

странно что не 100%

И чего тут странного. Можно установить CDT плагин и писать на С/C++. CDT глюкалово еще то, но всё равно для линукса ничего больше вменяемого нет.Вот может когда KDevelop новый допилят можно будет посмотреть.

А за что его ненавидеть?

Так тормозит, что пипец. Я не знаю, что там тормозит, их серверы, или ещё что то, но простые задачи вроде обновления списка пакетов, с которыми aptitude справляется за 20 секунд, в эклипсе занимают минут 10. Изредка при попытке что-нибудь установить вылазит длинное и страшное сообщение об ошибке. Нередко при не очень хорошем интернете оно качает часа два и в итоге вываливается с read error. Это только то, что сходу вспомнилось. Абсолютно непонятно, сколько ещё ему осталось качать. Скорость закачки можно увидеть только развернув окно прогресса на всю ширину экрана. В итоге чаще всего проще руками скачать zip-архив сайта и натравить эклипс на локальный репозиторий. Вообще отвратительная часть эклипса, имхо. Хорошо, что используется она крайне редко, день поматеришься, всё что надо поставишь и забудешь.

И какую версию плагин-менеджера Eclipse вы имеете в виду?

Юзаю эклипс примерно с 3.2, ругаюсь на этот менеджер столько же.

Все юзают гит, допотопный свн уже никому не нужен

Статистика в посте говорит об обратном, и она очень похожа на реальную. Я не против других систем, чем больше разных систем, тем больше прогресс. Но то, что svn - самая популярная система версионирования среди окрытых - голый факт, и логично плагин для него распространять сразу вместе с эклипсом.

Каталог с исходниками из SVN у меня на сорцах FreeBSD занимал в три раза больше места, чем каталог из CVS.

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

Кроме этого, в синхронизованном с CVS каталогах нету никаких левых/служебных файлов.

С этим согласен, немного неудобно, но жить можно.

>Так тормозит, что пипец. Я не знаю, что там тормозит, их серверы, или ещё что то, но простые задачи вроде обновления списка пакетов, с которыми aptitude справляется за 20 секунд, в эклипсе занимают минут 10.

Я использую Eclipse 3.4.2. Не замечал, что менеджер плагинов сильно тормозит. При обновлении он в фоне скачивает некий архив (можно последить за прогрессом, открыв окно «Progress»). Возможно, из-за ширины канала кажется, что он тупит и не сразу строит дерево доступных плагинов, но после скачивания индекса тупняков на 10 минут вроде нет.

Также при выборе и расстановке галочек над требуемыми плагинами происходит проверка зависимостей выбранных модулей от других. Но это никак не «10 минут».

>CVS не имеет возможности отслеживать mv, отсутствие отслеживания поддиректорий в параллельных ветках, приходится ~PRUNE делать чтобы от убивал пустые директории.

Хорошо. Вот рассмотрим такой пример. Разработчики решили удалить подкаталог со старым исходным кодом в дереве каталогов. В CVS-дереве на сервере он удалился. Логично предположить, что этот же подкаталог удалится и у пользователей, синхронизирующих каталог с исходными кодами у себя на компьютерах. (Или нет?)
Далее. Разработчики создали новый подкаталог с исходными кодами в CVS-дереве каталогов на сервере. У пользователей после синхронизации он тоже создался. Логично? Логично.
Тогда какие проблемы с «mv» у пользователей?

Новости прошлого месяца - вышла бубунта, слакофилище, арчеводы бухают, Мандариву то продают, то выпускают.

Новости этого месяца - 154 345 123 закачек ОО, опросы джавакодеров. 1.5 мальтийских компьютера будут на СПО.

>>>26.9% - Java-разработчиков создают приложения для web.

21% - приложений для домашних компьютеров.

26.9% - приложений для серверных нужд.

100-(26.9 + 21 + 26.9) = 25.2% ответило честно : нифига... 8)

Моя основная претензия к менеджеру плагинов, что иногда он не может разрешить зависимости правильно. Т.е. выбрал галочками «хочу это и вот это», он выбрал что для этого надо, всё скачал, а установить не смог. Не совпали версии каких-то пактов в пятой цифре и привет.

Попробуй.. http://eclipsesource.com/en/yoxos/

Использую NetBeans - мне как-то больше понравился (может не потому что лучше, вопрос личных предпочтений, мне показался чуть быстрее он сам и написание кода вместе с ним)

Ява - Серверная/Web - тут конечно я бы не стал их в опросе разделять - связанные вещи все-таки. Или под Web понимается что-то другое?

GIT. Имхо, но удобнее чем свн при количестве разработчиков > 2. Хотя, честно признаться на него перешел несколько месяцев назад только.

Открытый код не тырю без строчек Copyright и лицензии. Только если Public Domain. В апстрим возвращать - не обязан (лениво), но код выкладываю всегда (если не закрытый проект изначально), и препятствий не создаю - последователь Столлмана (но коммерческих проектов не чураюсь, денюжка то всем нужна :)

>> the latest version requires Eclipse 3.4 or Eclipse 3.4.1.

Как он с 3.5.x ?

requires - требует

Таким образом, плагин не работает с еклипсом до версии 3.4. На 3.5 полет нормальный.

> Хорошо. Вот рассмотрим такой пример. Разработчики решили удалить подкаталог со старым исходным кодом в дереве каталогов. В CVS-дереве на сервере он удалился.

Ага, удалим каталог на сервере вместе со всей историей правок. Гениально!

>GIT. Имхо, но удобнее чем свн при количестве разработчиков > 2.

Лично для меня DVCS удобнее в любом случае. Недавний случай: у заказчика упал SVN-сервер и работа встала. С Mercurial я бы просто продолжал делать коммиты (вернее, я бы оформлял это дело в виде mq-патчей, но это детали). А ещё мне иногда приходится уезжать. С Mercurial я могу продолжать работать хоть в поезде, а для SVN нужен инет. Такие дела.

>Опрос проводился среди посетителей eclipse.org

69.5% разработчиков используют Eclipse для программирования на языке Java

подозреваю если проводить опрос на сайтах netbeans или jetbrains результат будет противоположный.

>> Все юзают гит, допотопный свн уже никому не нужен

отучаемся говорить за всех. Все enterprise-level продукты используют svn. Ваши git bazaar mercurial - для поделок-однодневок.

жжешь неподецки!

Хоть разницу между ними знаешь и какие проекты их используют?

>> Каталог с исходниками из SVN у меня на сорцах FreeBSD занимал в три раза больше места, чем каталог из CVS.

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

Порнуху значит не качаем?

Хм....

Дурак. Прочитай GPL. Как же всякие сявки любят громко и истерично рассуждать о том, в чем не разбираются. Бесит!

> Сообщество Eclipse провело опрос о предпочтениях Java-разработчиков

69.5% разработчиков используют Eclipse для программирования на языке Java

а остальные 30,5 % java-разработчиков не программируют на java?

Вот одно время пользовался явой (писал маленькую утилитку) и так и не допёр, почему в Яве нет простых беззнаковых типов.. Как без них жить? Как работать с бинарными файлами, различными форматами, протоколами? Или просто тупо ложить меньшие по размеру беззнаковые типы в большие по размеру знаковые? Это же в два раза больше памяти жрать!.. Какой в этом смысл? Я когда писал, мне производительность была важна, поэтому пришлось JNI подключать, но неужели за всё время существования Ява никому не понадобилось сделать простой нативно-совместимый набор простых типов для Явы? Это же позволило-бы ускорить её в десятки раз.. Или я чего-то не понимаю..

Мне ни разу за всё время программирования на джаве не понадобились беззнаковые типы. Для байтов есть тип byte. Не могу себе представить ни одного случая, когда наличие беззнаковых типов позволило бы ускорить что-либо вообще, не говоря уже о десятках раз.

Ну тогда объясни, как ты поступаешь, когда считываешь из бинарного формата один байт. В файле он беззнаковый, у тебя он знаковый. Как ты получаешь его настоящее значение в Яве, обрабатываешь и записываешь обратно в файл?

В файле не лежат знаковые или беззнаковые числа, в файле лежат байты. Байт это 8 битов. Он не подразумевает знак. Как его интерпретировать - решает программист.

Уточни задачу. Вот тупой код, который записывает в качестве выходного байта нижний байт квадрата входного байта, интерпретированного как беззнаковое целое число.

        int c;
        while ((c = inStream.read()) != -1) {
            outStream.write(c * c);
        }

Ну вот, то о чём я и говорил: ты записываешь переменную размером в один байт в переменную большего размера. Этим самым кушаешь лишнюю память. А если тебе надо обработать сразу большой буфер с байтами? Каждый гонять в int и обратно? Что бы было понятнее, допустим надо брать не корень числа, а делить число на три (с отбрасыванием остатка) и записывать результат обратно в файл. Если бы в Яве простые типы были нативносовместимыми всё это можно было бы сделать не выходя из размерности байта. Хотя понятно, что даже int в Яве судя по всему не соответствует нативному int, а является неким недо-объектом, что вызывает ещё большие тормоза, но зачем тогда сделали целый зоопарк знаковых типов разной размерности? Сделали б уже тогда один целочисленный тип без границ..

int? Замечательно.

Задача №1. В файле лежат бинарными образом записанные 32-битные целые без знака, их надо считать, вычесть 12345 и записать во второй файл/поток. (Если число меньше 12345, записать 0).

Задача №2. У вас 10 миллионов структур, состоящих из а) строки фиксированной длины в 8 символов и б) идентификатора (целое 32-битное неотрицательное число). Эти структуры должны быть считатаны в оперативную память, заняв не более 150 мегабайт.

s/считатаны/считаны/

Ну вот, то о чём я и говорил: ты записываешь переменную размером в один байт в переменную большего размера. Этим самым кушаешь лишнюю память.

3 лишних байта на стеке? Это не серьёзно.

А если тебе надо обработать сразу большой буфер с байтами? Каждый гонять в int и обратно? Что бы было понятнее, допустим надо брать не корень числа, а делить число на три (с отбрасыванием остатка) и записывать результат обратно в файл.

Сформулируй конкретную задачу, я всё ещё тебя не понимаю. Да, временные переменные будут int, они обязаны быть int, иначе это будет медленно работать. Скорее всего в С переменная char реально будет в 4-х байтовом регистре. Потому что процессоры работают со словами а не с байтами.

Если бы в Яве простые типы были нативносовместимыми всё это можно было бы сделать не выходя из размерности байта. Хотя понятно, что даже int в Яве судя по всему не соответствует нативному int, а является неким недо-объектом, что вызывает ещё большие тормоза, но зачем тогда сделали целый зоопарк знаковых типов разной размерности? Сделали б уже тогда один целочисленный тип без границ..

Ты не понимаешь о чём говоришь, судя по всему. int это 4 байта, long это 8 байтов, byte это 1 байт, short это 2 байта, char это 2 байта. Нет никаких недо-объектов. Тип без границ тоже есть, это BigInteger/BigDecimal.

>Тип без границ тоже есть, это BigInteger/BigDecimal.

Вот это похвально, да.

>3 лишних байта на стеке? Это не серьёзно.

при больших обёмах данных, думаю оч. серьёзно. см. комментарий JackYF

Скорее всего в С переменная char реально будет в 4-х байтовом регистре. Потому что процессоры работают со словами а не с байтами.

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

Ты не понимаешь о чём говоришь, судя по всему. int это 4 байта, long это 8 байтов, byte это 1 байт, short это 2 байта, char это 2 байта. Нет никаких недо-объектов. Тип без границ тоже есть, это BigInteger/BigDecimal.

Про BigInteger знаю, это нормальный обьект, а не элементарный тип. Я же о элементарных типах и о том что они какие-то «неправильные». Вот ты говориш «судя по всему. int это 4 байта», но ява не даст просто так скормить массив таких интов нативному коду (через тот же JNI). Соответсвенно думаеться, что там вполне возможно храняться ещё какие-нибудь данные (вот я и говорю недо-обьект). Но дело даже не в этом - зачем создавать знаковые типы разных размерностей и не создавать беззнаковых?

Массив int-ов, это, естественно, не массив в С-шном понимании, у него есть ещё размер и прочее. Конкретно int это int, и если мне память не изменяет, он JNI-коду и передаётся как 4-байтовый int.

Задача 1: Поскольку не указано, буду считать, что числа лижат в big-endian.

    
    static void process(InputStream inStream, OutputStream outStream) throws IOException {
        long buffer = 0;
        int counter = 0;
        int c;
        
        while ((c = inStream.read()) != -1) {
            buffer <<= 8;
            buffer |= c;
            ++counter;
            if (counter == 4) {
                counter = 0;
                buffer = buffer < 12345 ? 0 : buffer - 12345;
                writeAsInt(outStream, buffer);
            }
        }
    }
    
    static void writeAsInt(OutputStream outStream, long num) throws IOException {
        for (int i = 3; i >= 0; --i) {
            outStream.write((int) (num >> (i * 8)));
        }
    }

да, но там всегда происходит копирование, тоесть ява копирует значение из своей переменной в переменную C. Тоже и с массивами - можно только скопировать, причём средствами JNI, на прямую прочитать массив или переменную из памяти VM никто не даст, соответственно, сложно сказать как такие переменные храняться внутри VM. поэтому тут всегда тоже происходит копирование и двухкратная потеря памяти.

2-ю задачу на джаве решать нецелесообразно. Общий подход - просто считать всё в память как массив byte[], и когда нужно вытаскивать нужную структуру - на месте её десериализовывать (и сериализовывать, если нужно сохранить).

>Оверхед - 4 байта.

А сколько преобразований типа? ;)

да, но там всегда происходит копирование, тоесть ява копирует значение из своей переменной в переменную C.

При вызове функции всегда происходит копирование значений в регистры или в стек. Не понимаю претензий :)

Тоже и с массивами - можно только скопировать, причём средствами JNI, на прямую прочитать массив или переменную из памяти VM никто не даст, соответственно, сложно сказать как такие переменные храняться внутри VM. поэтому тут всегда тоже происходит копирование и двухкратная потеря памяти.

Цена кроссплатформенности, видимо. Не хотели обязывать реализаторов VM хранить данные в каком то чётко определённом формате.

А сколько преобразований типа? ;)

Преобразование примитивных типов происходит без оверхеда, никаких проверок на переполнение и прочее не производится. Не думаю, что на С/С++ код выглядел бы иначе.

Итого, здесь мы потеряли в скорости. Сишный код быстрее за счёт чтения по 4 байта, а не по одному, отсутствия битовых преобразований и лишнего счётчика.

>Цена кроссплатформенности, видимо. Не хотели обязывать реализаторов VM хранить данные в каком то чётко определённом формате.

Так нативный код всё-равно платформозависимый, смыслу в этом, разве что в погоне за мифической безопасностью VM.

2-ю задачу на джаве решать нецелесообразно. Общий подход - просто считать всё в память как массив byte[], и когда нужно вытаскивать нужную структуру - на месте её десериализовывать (и сериализовывать, если нужно сохранить).

А если надо в рилтайм? Тут полюбы - либо прийдёться тормозить либо есть память..

>Общий подход - просто считать всё в память как массив byte[], и когда нужно вытаскивать нужную структуру - на месте её десериализовывать (и сериализовывать, если нужно сохранить)

Это выход. Но, опять-же таки, значительно теряем в скорости доступа.

Итого, здесь мы потеряли в скорости. Сишный код быстрее за счёт чтения по 4 байта, а не по одному, отсутствия битовых преобразований и лишнего счётчика.

Можно пример? Как это чтение по 4 байта и отсутствие битовых преобразований? Как из платформенного порядка байтов перейти к big-endian?

Так нативный код всё-равно платформозависимый

Почему? Если писать нормально, то вполне платформонезависимый (с перекомпиляцией, конечно).

смыслу в этом, разве что в погоне за мифической безопасностью VM.

Вряд ли, JNI и безопасность это очень противоположные понятия :)

А если надо в рилтайм? Тут полюбы - либо прийдёться тормозить либо есть память..

Общая задача неясна. Если 150 мегабайтов это максимум, и речь идёт о серверном приложении, то это не серьёзно, увеличиваем требования к серверу до гигабайта и не морочим себе голову. Если от 150 мегабайтов никуда не деться, опять же не морочим себе голову и пишем на С/С++, они для этого и нужны.