Обсуждение:Жаба

Материал из Lurkmore

неймфаги запилите http://img265.imageshack.us/img265/6843/mathq.png

вы про каждую хуйню с лора статью создавать будете? епта жо чего ж крансоглазики тупы!!!111

А вы про каждую хуйню с двача статью создавать будете? епта, до чего-же… Tenebrosus Scriptor 21:54, 7 марта 2008 (MSK)

значимость, значимость…

Лора? Или двача? Tenebrosus Scriptor 02:03, 9 марта 2008 (MSK)

двач понятен всем, в отличие от вашей задротской хуйни, интересной паре десятков девственников

ЛМ не только для быдла. Tenebrosus Scriptor 15:53, 14 июня

Мне понятен. Быдло

2008 (MSD)

[править] Война правок

Лютобешенно реквестирую отменить правку жабофага WARRGH от 17:30, 20 сентября 2010. Выпилил, гад, тонну ненависти, как будто его любимая жаба и жабакодеры от этого лажать меньше станут. Фапать на жабу в каком-нибудь другом месте нужно, бля! Так что если никто не докажет мне обратного, откачу все нахрен сам.

[править] Томми

Он же стал героем, вроде, из-за перегрева, говорили, а жаба там просто удачно оказалась?

Всем похуй.

[править] Ы?

А где про жабу, которая душит?

[править] Плохому танцору..

Современные виртуальные машины java по скорости не уступают нативным языкам^{[ЩИТО?][1]}, а функционала хватает практически на любую прикладную задачу. В особо тяжелых случаях можно прицепить либу на другом языке (хоть на ассемблере).

Проблема явы в том, что она обманчиво проста. На первый взгляд всё элементарно, но на самом деле в языке куча подводных камней. Особенно это касается оптимизации, правильно работающий код может работать в дофига-и-более раз медленнее чем мог бы из-за какой-нибудь не принципиальной на первый взгляд мелочи вроде выбора типа коллекции. Поэтому хороший ява кодер должен знать как работает любая нативная функция, а не тупо юзать их как черный ящик. Другой вопрос что это подразумевает необходимость курить исходники и мануалы, курить много, долго и муторно. А зачем, если «и так работает»? Вот и получается, что хороший язык присмотрели быдлокодеры, из-за которых слово «ява» стало чуть ли не ругательством.

«не принципиальной на первый взгляд мелочи вроде выбора типа коллекции» а няшная сишка или что-угодно-есчо к этому нечувствительны? это называется алгоритмической оптимизацией, что к языку или среде исполнения не имеет никакого отношения. Есть другие проблемы, технические. Например, оптимизация по кол-ву создаваемых экзэмпляров классов, что влияет на скорость и о чём очень навязчиво идеологи жабы советуют не думать («наша революционная JVM всё соптимизирует за вас»). Быдло и радо. А результат очевиден.

Няшная сишка чувствительна ко всему, но идея из предыдущего коммента полностью верна. Простой пример — синхронизация потоков. В «няшной сишке» нужно будет использовать нативный интерфейс ОС, или библиотеку типа pthreads, a специфика языка заставит хоть на сколько-нибудь изучить вопрос «что такое мьютексы с семафорами». А в Жабе можно просто взять и нахуячить слово synchronized везде, где левая пятка положит — и при унитарных тестингах это вполне себе будет работать. А при стрессовых интегральных — тормозить до ужаса и сыпать исключениями о зависших threads. Обычно интегральные тесты проходят на завершающих этапах разработки, а тут выясняется, что нужно до хрена переделывать, из-за вот такой вот фигни.

[править] Кто писал эту статью?

Расстрелять!!!

1. Я за то, чтобы статьи писали люди, хоть немного разбирающиеся в вопросе.

2. Кто ещё JS сюда примотал?

Немного доработал на тему адеквата. Но нужны лулзы и много.

Почему убрали список разновидностей Java? Да и вообще нанесли в статью много мусора. Старая версия лучше.

Какой идиот выпилил кучу лулзов из статьи? Анальная боль быдлокодеров-обезьянок?

Соглашусь с предыдущими ораторами — писал упертый жабоеб. Сплошные прославления.

[править] В разделе НЕНАВИСТЬ

Аноним интересуется: зачем курить исходники виртуальной машины?

JVM как и железо имеет свои характеристики.

ИМХО, этот раздел нужно выпилить кем, ибо любой из описанных в нём недоаргументов можно парировать, к примеру:

1. Javadoc, Tutorial’ы — так написанные, что и дэбил поймёт. Дохуя книг.

2. То жаба кого-то «лишает» программинга, то, блджад, имплементацию впадлу писать. Да и вообще, о чём можно говорить с таким количеством классов.

3. RTFM!!!11

4. Чьё-то «ЩИТО?» очень красноречиво…

5. Да, да, это вам не вижуал бэйсик. А так: swt, awt, swing…

6. Пруф говно, так как известны случаи когда солнечные пороли хуйню в исходниках (к примеру, класс Vector).

[править] Кто блять это писал?

Статья написана предвзято и убого. Афтар фапер настолько, что кленясь в вечной любви жабе, вставил даже пидарское (извините) сравнение жабы с Ц. Любой адекватный человек не будет сравнивать интерпретатор с компилятором. Я молчу что ц++код отлицается от явовского + сам по себе кривой. Вообщем — Переписать всё нафиг

Перепишите. Утверждаю. И что б побольше ненависти. Linefused 07:37, 30 сентября 2009 (MSD)

Почитай про JIT, потом пиши дальше свои «умности» --80.255.89.148 16:21, 2 ноября 2010 (MSK)

Запомни, школота! «JIT» значит лишь то, что компиляция динамическая. А то, что она неебически крутая.

[править] Целесообразность быдлокода

Обычно такая «целесообразность» является порождением непроходимой тупости менеджмента, ни хуя не понимающего в технической стороне вопроса. Менеджмент покупается на индусские предложения привлечённый относительно низкой (начальной) ценой и обещаниями крайне быстро сдать проект. А на практике разработка длится вчетверо дольше намеченного. Но уже поздно, деньги вложены, и менеджменту приходится продолжать поддерживать эту инициативу (и продолжать платить), потому что иначе — не будет ни проекта ни денег и нужно всё начинать с начала. Уплатив в итоге сумму, которой было бы вполне достаточно для оплаты труда квалифицированных специалистов, взыскательный менеджмент получает монструозную вундервафлю, 600% редундантную, заплатка на заплатке, с кучей багов и недоработок — но делать нечего, высшее руководство уже ругается, и приходится по-быстрому решать вопрос внедрения, зачастую закупая дополнительное оборудование, что опять увеличивает затраты. А учитывая, что индусский код по определению unmaintainable, поддержка и модификация купленной за бешеные бабки хуйни либо невозможны в принципе (то есть что бы внести нужное изменение, надо буквально всё переделывать), либо стоят ещё одни бешеные бабки и требуют туевой хучи времени. А «энтерпрайз» навсегда остаётся на крючке у ушлых индусов, создателей вундервафли, кроме которых в её коде понять никто ничего не может.

Ну пиздец, тупость менеджмента — это когда заказывают написать что-то очень большое на Си, срывают все сроки и ещё 10 лет отлавливают баги. Вот это тупость по настоящему. --80.255.89.148 16:24, 2 ноября 2010 (MSK)

Чего-то я не догоняю. Т.е. ты считаешь, что когда заказывают писать что-то большое быдлокодерам на любом языке, срывают все сроки и ещё 10 лет отлавливают баги (выплачивая за это большие деньги) - это пиздатый толковый менеджмент? И причём тут С?

[править] 4-5 раз

Если даже забыть о том, что такие значения надо хранить в виде скаляров, стоит заметить, что для sun hotspot 1.6 размер ссылки на объект равен размеру void* для того же окружения в С++, а размер инстанса Object — 2x(void*). Где тут в 4-5 раз?

Плюс размер каждого объекта дополняется до кратного восьми (на 32-битной HotSpot). Итого для хранения одного жабьего class XYZ { public byte x, y,z; } нужно 20 байт, а для struct XYZ { public byte x, y,z; } — 3 байта. Если хранить в скалярах, то жабокодеру нужно выделить массив байтов и принять, что в его отсчетах последовательно чередуются x, y,z. Каково? Ништяк ведь?

Я создал 1000000 объектов на 32bit JVM. Это заняло 8М памяти. Где тут выравнивания до неких сферических восьми? ЧЯДНТ? + учтите, что ваш struct обязательно будет выровнен в памяти под размер регистра на каждую переменную — итого будет не 3 байта, а 12 (x32) или 24 (x64). Ну и для работы с RGB данные НАДО упаковывать (экономия на указателях + локализация данных). В С/C++/C# это сделать проще (есть структуры), не спорю. А цифры писать от балды нехорошо.

Так, само по себе выравнивание теоретически возможно (только не до кратного восьми, а, скорее, до размера машинного слова). Только всё равно разницы в 4-5 раз не наблюдаю. Как и размера Object в 20 байт.

Сказал — в лужу пёрнул. Насчет выравнивая до 8 байт читать здесь: http://www.javamex.com/tutorials/memory/object_memory_usage.shtml Размер struct XYZ хоть в Си, хоть в Си шарп 3 байта, а выравнивание в структуре производится вовсе не так, как ты думаешь. Оно производится так, чтобы каждый объект был выровнен на нужную ему границу. Байты вообще в выравнивании не нуждаются, следовательно и вся структура XYZ не нуждается (выравнивать ее понадобится только если надо будет ее передать на стеке как аргумент в другую функцию — что нисколько не беспокоит, если мы не пишем рекурсию глубиной over 9000). Причем если надо, выравнивание для полей можно вообще отменить. Нахуй мне твои пустые объекты, да еще и без ссылок на них. Чтобы XYZ в массив или другой контейнер положить, нужна ссылка (4 байта) + инстанс объекта (8 байт) + данные (8) = 20. Проверил на 32-битной Java HotSpot™ Client VM (build 11.2-b01, mixed mode, sharing). Между первым и вторым nextInt() выделяется 21.5*k байт памяти. Так что получается даже не 4-5, а семь раз. Упаковка — костыль, не выполняющий никаких полезных функций. Код:

import java.util.*;4
 
	class XYZ {
		public byte x,y,z;
	} 
 
 
public class manyXYZ {
 
   public static void main(String[] args) {
		Scanner in = new Scanner(System.in); 
 
		int k = in.nextInt();
		XYZ q[] = new XYZ[k];
		for(int i=0; i<q.length; i++){
		    q[i] = new XYZ();
		}
 
		int idx; // Делаем что-нибудь, чтобы компилятор не соптимизировал чего не надо
		while( (idx = in.nextInt())	!=0	) {
			System.out.println(++q[idx].x);
			System.out.println(q[idx].y^=2);
			System.out.println(q[idx].z--);
		}
   }
 
}

Так, проверил для GCC C++ (установки по-умолчанию, архитектура x86) — структура занимает 3 байта. Аналогичный класс в жабе — 16 байт, + 4 на ссылку на инстанс.

Объясните, граждане, нахуя мне массив RGB значений на жаве? А ворочать несколько сотен тысяч записей из базы на любом языке накладно.

Справедливости ради надо отметить, что в большинстве реализаций C++ при множественном наследовании в объекте может оказаться (а может и не оказаться) больше одного указателя на vtable, и тогда теоретически жаба использует память экономнее чем C++, а в гнутой жабе пустой объект содержит только один указатель. Но всем похуй.

Насчёт выравнивания. Разные есть виды. Есть под размер линейки кэша (для отсутствия чтения данных из двух линеек сразу — в таком случае будет пенальти). Это случай сан JVM под х86. Бывают и другие варианты: взять хотя бы http://www.opennet.ru/base/dev/porting_code.txt.html (раздел выравнивание) Для большинства RISC структура в С++ занимать 3 байта не может — ибо при попытке чтения данных (в лоб) по нечётным адресам процессором обязательно будет сгенерирована ошибка. Так что или эмуляция чтения по «неудобным» адресам со стороны компилятора (ценой падения производительности), или выравнивание. итого действительно при таком идиотском хранении данных в жабе разница получается для x86 (при упоре С++ компиляции на минимальное потребление памяти) в 6.67 раз. Для других архитектур/настроек возможны варианты. Взять хотя бы: http://www.linuxquestions.org/questions/linux-software-2/g-on-64bit-machine-alignment-issue-684971/ В целом, утверждение там справедливое. Добавлю только сноску, что данные надо упаковывать. Под упаковкой я в данном контексте понимаю не boxing/unboxing, а представление данных в виде массива. Например xyz0.x = a[0], xyz0.y = a[1], xyz1.z = a[5].

Первая ссылка вообще про C а не про ++/#, на которых так не пишут. Как выравнивать поля структур и побыстрее копировать это дело компилятора, а не мое, а я указываю компилятору /O2 или -O2 и размер получается 3 байта. Тип с тремя примитивами нормальный, обычное ООП, а у подобной упаковки читабельность и типобезопасность на уровне ассемблера. Идиотский здесь только язык, который такой только потому, что у создателей почесалось левое яйцо и они выпилили значимые типы из языка найух.

С не С — пример был о вариантах выравнивания структур. С остальным согласен. Порой идеализация ООП и фанатизм в следовании его идей при дизайне языка доставляет неприятностей.

[править] Shootout

Типичный бенчмарк ни о чём. Где хотя бы исходники тестов? Что конкретно мерялось — куча, память процесса?

Не, это очень нетипичный бенчмарк, который а) не заявляет о себе что он правильный б) задачи хотя бы отдаленно похожи на реальные в) проверяется выхлоп программы г) и любой желающий может засабмитить свою реализацию (хаскелянты, например, недавно на несколько миллисекунд переплюнули цепэпэ на pidigits). Измеряется полная память процесса, а не то сишники положили бы все данные в статическую памяти, и потребление памяти — ноль :))

Возьмем жабу. Версия ЖВМ? Серверная или клиентская? Код «прогревался» перед тестами? Разница в результатах даже если эти факторы менять — в разы. Не говоря уже о GC и прочем. Версия и тип ЖВМ указаны, но этого мало. А мерять память процесса для такого рода задач, которые в реальных программах представляли бы собой одну утилитную функцию, немного неверно. ибо интерпретаторы/виртуальные машины заведомо проиграют. Чарт там к тому же хз что показывает — координатные оси в попугаях. исходники реализаций есть (правда, сходу фиг найдёшь) — тут вопрос снимается. А в целом, неблагодарное это дело, такого рода фаллометрия.

Все там написано, и что код прогревался 65 раз. Даже если ограничиться бенчмарками, на которых цэпэпэ потребляет >100 Мб памяти, ситуация не намного лучше: [[1]], и жаба (даже -Xint) все равно памяти кушает больше, чем иные интерпретаторы. Хотя могу сказать, что один бенчмарк там на 100% высер — thread-ring. Программа ничего не делает, а потом выводит одно число.

То, что кушает больше, понятно. Жава и рациональное использование памяти — слабо совместимые понятия. Таковы уж принципы работы JVM и ограничения языка, что чтобы не занимать много памяти в процессе работы, нужно сильно постараться. | Прогревать JVM до запуска теста в принципе невозможно, ибо там меряется время выполнения процесса (или я ошибаюсь?). То есть если прогрев и имеет место (по коду жава-приложений это не видно), то время прогрева добавляется к тотальному результату. | А так убедил — тесты эти, пожалуй, одни из лучших из того, что есть, если повнимательней на них взглянуть. Но всё равно это всего лишь тесты. Реальность иная (и не обязательно в пользу Жавы).

Я не знаю, как кэширует и кэширует ли вообще серверная JVM код, но можно посмотреть время выполнения при малых N [[2]] и убедиться, что время старта не может определять двухкратное отставание по скорости при больших N. Эффективно использовать память на JVM можно: достаточно оттранслировать паскаль или цэ в JVM, они там выделят массив байтов и будут расходовать экономно.

[править] Примечания

1. ↑ В общем и целом — никакая интерпретирующая среда никогда не сможет исполнять код в точности с той же скоростью, с которой он выполняется будучи откомпилированным. Я гарантирую это! Да, для определённых задач и определённых участков исполняемого кода, джавовские JIT-компиляторы могут выдать сопоставимое быстродействие. Но! Аффтар, не забывайте о том, что наряду с вашим конкретным приложением, так же исполняется и вся JVM. Все эти бенчмарки, где Джава якобы работает так же, а по материалам самого Солнышка — в десять раз быстрее (разумеется!), чем компилируемые языки, считают только чистое время исполнения кода задачи в лабораторных условиях — с супероттьюненной под конкретную задачу JVM и отключённым сборщиком мусора. А в плане всего комплекса реальных задач Джава всегда будет медленнее. Просто обычно бывает неважно — ждёт пользователь 3 сотых секунды, или 3 стотысячных — человеческое восприятие этого всё равно не различает. Но если речь идёт, к примеру, о массовой обработке транзакций (сотни тысяч в минуту), Джава — не лучший выбор, а зачастую и вообще не выбор, ибо не потянет, даже на очень крутой машине.

[править] Перенаправление с java сделайте!

Хуй найдешь ведь.

[править] В жабе нет указателей?

А это что?

import java.util.*;
 
public class Moo {
    public static void main(String[] args) {
    	int[] x = {1,2,3};
    	int[][] y = new int[8][];
 
        System.out.println(x);
        y[0][0]++;
    }
}

выводит (под вендой):

[I@42e816
Exception in thread "main" java.lang.NullPointerException
        at Moo.main(Moo.java:10)

Петровичу больше не наливать. Где в жаве тип «указатель на …»? NullPointerException — атавизм, правильне было бы назвать NullReferenceException.

Уж ежели приспичит…

public class Ptr<O> {
   public O ptr;
}

То, что в жабе называется ссылками, в паскалях и оберонах называется указателями. В оберонах и ди указатель при необходимости неявно разыменовывается. Очевидно, что авторы жабы поменяли терминологию маркетинга ради. (А я сам нехило удивился, что в жабе можно распечатать указатель.) А собственно ссылок в жабе нет. В языках, где есть ссылки, можно написать функцию/процедуру, которая меняет содержимое своих аргументов местами. В жабе этого сделать нельзя.

1) То, что в жаве называется ссылкой, прямого аналога в паскале не имеет. Указатель подразумевает адресную арифметику. В жабе её нет. 2) Если непонятно, как в жабе через ссылку поменять состояние обжекта — то почитай книжки по сабжу сначала. Если не поможет — помогу демонстрационным хэлловорлдом. 3)То, что распечатывается — это хэш-код, который, строго говоря, зависит от реализации. Ну и даже от Сан в 64х жабе что распечатается, когда указатели там 64-битные, а sizeof(int) = 4? Что за мода такая — выдавать детали реализации за спецификации?

Ололол, Undefined Behaviour в жабе. А вот это можно перевести на жабу?

procedure swapint(var x,y : integer);
  var temp : integer;
  begin t:=x; x:=y; y:=t; end;
var a,b : integer;
begin
  a:=4; b:=7;
  swapint(a,b);
  writeln(a,' ',b);
end.

Указатель нихуя не подразумевает адресную арифметику. В паскале изначально указатели были, но адресной арифметики не было и ее прикручивали как попало. Алсо, читаем статью про указатели Фортрана: http://hilbertastronaut.blogspot.com/2009/03/dark-secrets-of-art-c-pointers-and.html. 3) нихуя не хэш-код. для двух разных объектов с одинаковым содержимым он разный. распечатывается указатель. можешь с помощью GDB приаттачиться и посмотреть.

1) Батенька, в жаве нет передачи аргументов по ссылке. Чтобы сделать Swap, нужно создать class {int x, int y}, передать его инстанс в функцию и менять значения уже там 2) Указатель может указывать на что угодно в памяти. Это просто адрес. В жаве ссылка или null или указывает на Object требуемого типа. Третьего не дано. 3) читай спеки для начала. Единственное требование к хэш-функции — одинаковые значения для equal Objects. По-умолчанию разные инстансы Object друг для друга не equals. Срочно в библиотеку! Стоит начать с жава-доков Object#equals(Object), Object#hashCode. Море новой информации гарантирую.

С адресами работают в ассемблерах и машинных кодах. Указатель, еще раз, вовсе не обязан быть адресом в памяти — стандарт языка Си этого не требует. Указатели на функцию член класса с виртуальным наследованием и вообще могут занимать в 3-5 раз больше, чем void*, в зависимости от реализации.

Стандарт языка Си о функциях-членах ничего не знает. Как и о ссылках. Если говорить о C++, то концептуальная разница между ссылкой и указателем описана в книжке Страуструпа «Язык программирования С++». Да и в целом — яблоки с апельсинами сравнивать не надо. Достаточно отметить, что указателей в Жаве нет. Насчёт стандарта С (лучше С++) — цитату было бы неплохо (просто для личного развития).

Лол, а указатели на функции-члены — не указатели, что ли? Пример указателей на данные, не являющихся адресами — дальние указатели в x86, где старшие 16 бит являются селектором.

Когда в жаве я смогу из какого-нибудь рандомного int получить указатель на что-нибудь, тогда в жаве появятся указатели. А пока что ступайте в сад со своими хэш-кодами и указателями на члены-функции в C++.

[править] Scanner

Также в ACM’е каждый жабокодер вынужден писать свой класс для чтения чисел из файла, так как встроенный в языкпоставляемый со стандартной библиотекой Scanner работает слишком медленно.

А про Integer.parseInt() et al. британские учёные молчат?

parseInt только преобразует строку в число, а надо еще открыть поток и распарсить — ваш К. О.

О ужас! Как же я на Турбо-Паскале с этим справлялся, будучи школьником?.. 3-х строчный код токенизации по словам текстового файла надо приводить? | Ну и в целом, стоимость парсинга файла — O(n), а значит, на стоимость решения вычислительно сложных задач не влияет (при отсутствии мегабайтных входных файлов или наличии буферизации чтения файла) | Да и в целом — жаба сама по себе тут не при делах. Все вопросы — разработчикам конкретной версии стандартной библиотеки.

Стоимость парсинга N чисел от 1 до N не O(N), а O(N*log N) — такие задачи встречаются часто, так что влияет. А на Паскале эта проблема не возникала потому, что read является частью языка, и компилятор заменяет read вызовами написанных на асме процедур.

«а надо еще открыть поток и распарсить — ваш К. О.». Специально для нашего К. О. — выделять лексемы руками из текстового файла и парсить их через Integer.parseInt(). Какие проблемы? Стоимость такой операции что на Жабе, что на Паскале что на Луне — асимптотически одинаковая. А если Scanner глаза мозолит — то язык тут ни при чём. | Ну и стоимость парсинга всё же O(n), где n — размер файла

O(1) still sucks for large values of 1. — К. О.

Гражданин К. О., если стоимость самой задачи N*N, то чтение файла со стоимостью O(1) в пределе на бесконечности роли играть не будет. Повторюсь также, что это проблемы конкретной реализации Scanner или твои, если в какой-то поставке JVM он тебя не устраивает. Язык тут ни при чём. Если ты хотел сказать, что у жабы для O(1) большая константа на операцию чтения, то можно побенчмарчить — парсинг файла на C (твоя реализация) и парсинг файла на жабе (моя). Если разница будет в 100 раз не в пользу жабы, тогда соглашусь.

Отлично, сравниваем scanf vs. readln vs. Scanner. Задача — прочитать сто миллионов чисел и вывести из них наибольшее. Файл надо сгенерить отдельной программой на жабе, чтобы убедиться, что все три программы читают одни и те же числа. Алсо, речь шла о сановской JVM/JRE, то есть самой правильной.

Ок. Только сравнивать readln (unicode) со scanf (ASCII) некорректно. Поэтому формат файла — сколько угодно чисел, разделённых пробелами (если угодно, разделителем строки '\n'). Некорректные файлы не рассматриваются. Я пишу свой парсер в наиболее на-скору-руку виде на жабе. Со Scanner и scanf сам давай.

Вот моя программа. Запускай с JVM опцией -server. Разделитель между словами — пробел. Кол-во чисел изначально неизвестно.

   import java.io.BufferedInputStream;
   import java.io.File;
   import java.io.FileInputStream;
   import java.io.IOException;
   
   public class Max
   {
       public static void main(final String[] args) throws IOException
       {
           int max = Integer.MIN_VALUE;
           final BufferedInputStream in = new BufferedInputStream(new FileInputStream(new File("c:/stuff/a.txt")));
           int i;
           final StringBuilder b = new StringBuilder();
           while ((i = in.read()) >= 0) {
               // conversion is safe just because it is know the file is ASCII.
               final char c = (char) i;
               
               if (c == ' ') {
                  if (b.length() > 0) {
                       final int num = Integer.parseInt(b.toString());
                       b.delete(0, b.length());
                       if (max < num) {
                           max = num;
                       }
                   }
               } else {
                   b.append(c);
               }
           }
   
           if (b.length() > 0) {
               final int num = Integer.parseInt(b.toString());
               b.delete(0, b.length());
               if (max < num) {
                   max = num;
               }
           }
   
           try {
               in.close();
           }
           finally {
               System.out.println(max);
           }
       }
   }

Угу. Это уже неправильно: мало того, что работать будет только с пробелами, если последнее число не имеет пробела после себя, то оно не будет обработано. Где генератор тестового входа? А вообще, речь шла о том, что именно Scanner работает медленно, и на контестах сишники пользуются обычным scanf, а явисты пишут немало кода.

1) Последнее число без пробелов обработано будет, можешь проверить. 2) Добавить какие угодно разделители — это разве проблема? if (c < '0' && c > '9'), если угодно. Формат «олимпиадных» текстовых файлов этого не требует. В других случаях код будет другим, опять же скоростной. 3) Речь потом зашла о скорости парсинга текстового файла — мой код парсит файл настолько эффективно, насколько эффективна работа жёсткого диска по чтению текстового файла. 4) Scanner, в его реализации от мозгов от Сан, — это убогое поделие, целиком завязанное внутри на регулярные выражения. использовать его для вычитки файлов больше пары килобайт будет только истинный быдлокодер. Программисту дан мозг для того, чтобы им пользоваться. 5) Предлагай свой код со scanf — посмотрим-полюбуемся (в хорошем смысле) 6) Генератор — создай файл, запиши туда 3 числа, а дальше — loop(ctrl+a? ctrl+c, ctrl+v) до нужного размера. За 20 итераций получишь нужного размера файл. Содержимое его для целей тестирования скорости парсинга неважно. 7) написание этого немало кода заняло минут 10. Много? Написание с использованием Scanner, scanf итп заняло бы раза в 2 меньше. Но, если scanf отдаёт нуль при кривом файле, то кто бы написал код быстрее? 8) Тестировать будем скорость? | Предварительные выводы от меня: 1) использование Scanner в его реализации от Sun для обработки простых текстовых файлов большого размера — показатель истинного быдлокодия и невыработанного навыка RTFM 2) проблемы это не вызывает практически никакой. Да и появился он в жабе этак шестой (может, пятой). До сканера жили жабакодеры и жить будут 3) к жабе, как к тормознутому _по определению_ созданию, кривая библиотека от одного (пусть и основного) дистрибьютора не имеет прямого отношения 4) Фразу про Scaner, если возвраСЧать в статью, то наверное, с переформулировкой — ибо его использование в контексте ACM неоправданно в принципе.

А хотя, можно даже не переформулировать, ибо всем ясно, на какой JVM запускают тесты. Я верну.

Тестирования производительности для подтверждения или опровержения «O(1) still sucks for large values of 1. — К. О.», похоже, не будет. А жаль. Всё как всегда — виновата жаба :) К. О. is so К. О.

Нефиг юзать тормознутый Scanner, чоткие пацаны юзают StreamTokenizer in = new StreamTokenizer(new BufferedInputStream(new FileInputStream(new File("a.in"))));

[править] В защиту метвых

J2ME в натуральных Siemens’ах обеспечивала написанным под Siemens мидлетам доступ ко всей файловой системе, в отличии от других производителей, ограничения стали появляться только в New SGold платформе.

[править] Java — это нэ толко ценый мэх.. но и анальная кара для недоучек

Заебали уже про память, JIT, указатели которые не указатели и прочие чисто языковые особенности. А Spring, JUnit, Struts, EJB (особенной третий), мульоны других фреймворков? Жава дала кучу идей тому же шарпу, да и всяким рубям с пехапе. Кстати, аннотации весьма кошерны. Ваш WebSphere-кун.

• Спринг - говно.

Это ты говно недоученное, а спринг уже стандарт в J2EE6, называется только CDI

Угу, и только не Спринг это вовсе, и нихуя не "стандарт".

В смысле - с чисто академической точки зрения DI и AOP - офигенные штуки (в теории). А на практике получается так:

В реальной практике а не на каникулах в школе получается децл по другому:

две технологии: контейнеры и ORM были в джаве практически всегда и долбоебы не понимающие зачем нужен спринг или хибернейт фактически не понимают зачем нужен энтерпрайз.

Подпись - долбоёб-школьнег на каникулах, который фактически не понимает зачем нужен энтерпрайз, зато где-то увидел умную аббревиатуру "Object-relational Mapping".

По делу есть что сказать, убогий?

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

спринг, как и любой контейнер, нужен в первую очередь для реализации модульности, убирания жестких связей между

твоими классами и нужно это всегда в любом проекте где код пишут более одного человека и нужно покрытие тестами.

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

В чем выражается "пиздец"? Жаба-Обезьян из Бангалора не осилил xml?

• Aннотации в том виде, в котором их используют рукожопые энтэрпрайзеры - говно. Додуматься ж надо сервлеты через аннотации описывать.

сервлеты появилась возможность описывать через аннотации только в j2ee6, используют ее пока только ради красивого понта.

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

это плохой кейс, так не делают.

ты так не делаешь? "отучаемся говорить за всех" ;)

да бля я так не делаю, и все нормальные программисты, работающие за деньги а не за еду так не делают. Потому что нет причин так делать.

Аналогичны все остальные потуги (веб-сервисы, ежыбы). Единственное где они нормально юзаются - JUnit 4, но при этом классический 3.8.2 и то получше выглядит. А стратс 1 весьма недурён!

дедушка, ты когда уже сдохнешь?

• Да и этот ваш WebSphere - говно. Очень тяжёлая ресурсовая жаба с неоправданно переусложнённым интерфейсом и deployment-архитектурой, где есть cells, nodes, servers, hosts, virtual hosts, node agents (и у всего этого ещё есть алиасесы и хрен знает ещё что), дибильные stubs для EJB-деплоймента и т.п. и т.д. Налицо желание буржуинов из IBM обеспечить себе экслюзивный заработок на фигне, которую для экспертного владения надо изучать несколько лет. В православном WebLogic'е тот же самый функционал доступен после двух-трёх кликов.

Перед вами выступал

Дядя Вова-наркоман

В твоем веблоджике все ровно точно также, с той лишь разницей что сфера работает а веблоджик глючит.

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

Слышь дятел, вся линейка Oracle (Weblogic->Suite->ESB) стоит где-то раз в 5 дороже аналогичной от IBM, это значит что за веблоджик платят больше. А твою вебсферу сейчас знает каждый второй Ашот с рынка. Причем оракл не жмется и дает качать практически все продукты в отличие от голубых, которые бесплатно дают только пососать член.

[править] Исключения

>Выполняются исключения медленно, если хранить в них данные о стеке (чего можно избежать). Покажите мне такую JVM, которая исключения обрабатывает так же быстро, как традиционные механизмы управления.

Плюсую. Покажите мне КАК можно избежать хранения данных о стеке в Sun Hotspot JVM.

[править] Чемпионы ACM ICPC

Самим не смешно приводить статистику из 3 точек? На ICPC жаба кажется еще с 2004 года есть. По правилам там не делается различия между программами, использующими 50% или 30% от лимита времени, поэтому тем, кто с самого начала пишет прямой код (а становятся чемпионами только такие) нет разницы на чем писать, так как эталонные решения тоже на жабе. Необходимость набрать немного больше ручками в формате ACM (5 часов, 3 человека) не представляет сложности, так как один человек набирает один раз и потом копируется. Другое дело — топкодер (75 минут, 1 человек), там такое не прокатит, поэтому входные данные передаются как параметры функции (недостаток этого — нельзя сделать доступной сдачу решений на большом числе языков)

[править] java vs limbo

Собственно, сабж. На limbo написана целая операционная система, быстрая и экономная к памяти, когда же на java даже hello world съедает сотни памяти. inb4: некрофил, упорот, плантард, «хайль юникс, хайль линакс, хайль иксэмэли, хайль ява!»

Почитал про лимбу. Похоже отличается от жабы главным образом, синтаксисом. Я что-то пропустил?

Ну во первых, в лимбо нет никаких ООП-извращений, но есть няшные классы типов (как в го или хаскеле) и есть CSP, с его помощью потоки общаются между собой через каналы. Во вторых, там регистровая виртуальная машина, когда же в яве — стековая. Регистровые виртуальные машины работают эффективнее стековых, по крайней мере на современных машинах. В третьих, там другая реализация управления памятью, и лимбо требует меньше ОЗУ, чем ява. В четвёртых — 9P (да, плантарды довольны). В пятых... ладно, пока остановимся на синтаксисе.

[править] Магическое число

Нужно куда-то добавить, что увидев число 2.2250738585072012e-308 Java виснет вглухую. Вызвано это ошибкой в реализации работы с числами с плавающей точкой. Уже запилено.