GD Star Rating
loading...

Коллеги, особенно те, кто пишет на java.
Может кто-то недавно по собеседованиям ходил…что сейчас “модно” спрашивать?
Особенно интересуют нестандартные вопросы на собеседованиях в различные большие конторы (например deutsche bank).

Админы и сочувствующие посетители hardblog.net посчитали злободневным:ножи, автоматы и оружие

Tagged with →  

85 Responses to Коллеги, особенно те, кто пишет на java.

  1. Sukon:

    Про unboxing, например.

  2. NieTunes:

    : Ну…ээ, а что про него спросить то можно?

  3. NieTunes:

    : вопрос снят, понял где там ньюансы

  4. Veaapp:

    Дойч спрашивает по Core Java. Какие типы/объекты сколько занимают в памяти, java memory model & concurrency, хип/стек, хэндлинг эксепшенов – всегда ли отрабатывает finally? вопросы про инициализацию и полиморфизм, generics.

    Был там прошлой весной. Собеседование понравилось, ребята адекватные.

  5. Aklre:

    ты спрашивать хочешь или отвечать?

    что такое default visibility и почему за это нужно отрубать по пальцу?
    можно ли во время выполнения узнать тип генерика?
    что о чём говорит строка float val = (float)someInt / 100f;

    чёт у меня вопросы не серьёзные…

  6. Kuyno:

    Если говорить про Дойче – зависит от команды. У нас тут есть и корка (и требуется действительно хорошее знание всяких потоковых премудростей), и энтерпрайзы/тибки. Видел, как на собесе одна команда спрашивала про no-gc setup – когда вся куча при старте программы выделяется и руками рулится. А другая просто спросила иерархию эксепшнов да когда дергаются конструкторы базовых классов.

  7. LanTunes:

    : а это правда необходимо знать, чтобы писать на яве?

  8. Lagapp:

    : ну сколько что занимает может и нет (если не нужно писать memory-constrained приложения), остальное да, практически основы.

  9. Veaapp:

    : смотря что. В Deutsche Bank на Java пишут в частности Low Latency системы.

    Вот их презентация с JavaOne http://www.oracle.com/ru/corporate/event…

    http://martinfowler.com/articles/lmax.ht&#133; – пример системы на Java, которая держит миллионы транзакций при latency < 1ms

    http://www.proprofs.com/quiz-school/stor&#133; – нашёл у себя ссылку на тест, который они присылали, но он уже недоступен. можете поискать на том сайте новые версии.

  10. Veaapp:

    : а какая jvm умеет отрубать gc?

  11. NieTunes:

    : : Про отключение gc тоже очень интересно.

  12. NieTunes:

    : отвечать:)

  13. Aklre:

    : тогда удачи!

  14. NieTunes:

    : ага, спс, но я не в ДБ, просто для примера привел

  15. NieTunes:

    А про “isoemo” тыц кто-нибудь слышал?
    Странно просто, вакансии давно уже висят, при этом все люди которые находятся в соц сетях и т.д. как правило там проработали не больше 4х месяцев и или уже работают в другом месте или 4 месяца еще не прошли.
    Как-то подозрительно…
    Инсайдеры есть?

  16. Erobad:

    Рассказать про устройство HashMap и что происходит когда случаются коллизии хэш-а.
    Что такое ReentrantLock.
    Что за метод String.intern
    Как конвернуть float в BigDecimal
    quicksort 🙂

  17. XawSport:

    Я могу за свои собесы рассказать.

    Начинается всё с класса Object и его методов. Суть вопроса не в том, чтобы наизусть API знать, а в том, что это приглашение к разговору сразу по нескольким топикам, а именно:
    a) контракт метода equals
    b) как устроена HashMap
    с) как в Java работает синхронизация

    По мере ответа на эти вопросы можно перескочить на разного рода каверзные вопросы по устройству коллекций, на продвинутые темы многопоточности (thread safety, JMM, java.util.concurrent). Ещё, бывает, задаю вопросы по фичам Java, появившимся с версии 5.0 (enum, generics, annotations, autoboxing).

    Казалось бы, не так всё сложно, но примерно 80% кандидатов отсекается уже на этом.

    Если человек по core Java нормально отвечает, можно по фреймворкам типа Spring/Hibernate погонять. Если и тут человеку есть, что рассказать, можно перейти к разговорам о паттернах, принципах ООП и методологии TDD.

  18. XawSport:

    На собеседованиях в Deutsche bank всё зависит от проекта, в который собеседуешься. Меня на собеседовании гоняли по core java, Swing-у (толстый клиент в проекте написан именно на нём), немного спрашивали про Spring и Hibernate.

    Подход был примерно такой. Есть некий опросник из 20 несложных вопросов, которые, однако же, являются лишь началом разговора, за каждым из этих простых вопросов скрывается по несколько сложных, проверяющих понимание.

  19. XawSport:

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

  20. XawSport:

    : за default visibility отрубать по пальцу? и почему же? у него же есть вполне конкретная область применимости.

  21. Aklre:

    : согласен. так точней: оцените в каком количестве случаев из ста в дикой природе стоит отрубать по пальцу программистам, использующим default visibility и почему.

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

  22. Ocser:

    как-то вы спрашиваете странные вещи, imho…то что можно подучить довольно быстро
    и то что я, например, почти и не помню :
    нафига про синтаксис языка спрашивать? я бы задавал какие-нибудь практические задачки
    и уже по подходу бы определял, годный чел или шлак.
    даже если не знает, но не тупит – есть перспектива и брать можно

  23. NieTunes:

    : Он в Arrays.sort используется(правда модифицированный), насколько я помню.
    Хотя я вообще не вижу смысла по алгоритмам сортировки спрашивать.
    На такие вопросы 2 типа людей ответить смогут, те кто недавно диплом получили и те, кто реально использует это в работе(согласитесь, для большинства задач хватает сортировки из CollectionsArrays).

  24. Erobad:

    : Я согласен что quicksort мало кто ответит, но хотя-бы одну сортировку человек должен написать и объяснить.

  25. Erobad:

    но я собеседовал только джуниоров, для них этот вопрос актуален.

  26. Aklre:

    : только бабл, только хардкор!

  27. XawSport:

    : В Java, как и в любой более-менее сложной системе, есть масса способов выстрелить себе в ногу. Мне вот интересно, чем вам именно default visibility не угодил. Я с этим языком давно дело имеют, и это, прямо скажем, не самая часто встречающаяся проблема. Излишнее использование модификатора public, к примеру, встречается куда чаще.

  28. XawSport:

    : Не, неправильно помните. Там используется модифицированный merge sort, а в случаях малого количество элементов – сортировка вставками. Я вот тоже не вижу особого смысла спрашивать по алгоритмам сортировки. Я парочку для приличия помню, но на практике их реализовывать ещё ни разу не приходилось.

  29. XawSport:

    : Про синтаксис спрашивать и правда смысла нет, а вот про концепции языка, которые используются каждый день, спрашивать надо. Как можно допустить до продакшн кода человека, который не понимает, как правильно переопределить метод equals? А если он не знает, как многопоточный код писать корректно? Это ж пиздец, каких монстров может наплодить такой программист. Ситуация с многопоточным кодом осложняется тем, что его чертовски сложно корректно протестировать, поэтому во многом приходится полагаться на понимание того, что там происходит.

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

  30. Aklre:

    : меня, не смотря на уже седины, до сих пор шокирует обращение на вы, поэтому если чо, то я за ты.

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

    коротко говоря, моя позиция такова: публичный класс не может иметь default visible методов. пока не могу придумать неоптимизационный случай когда она вообще может понадобиться для поля.

  31. NieTunes:

    : Неа, именно quicksort, даже в док залез:
    “Sorts the specified array of bytes into ascending numerical order. The sorting algorithm is a tuned quicksort, adapted from Jon L. Bentley and M. Douglas McIlroy’s “Engineering a Sort Function”, Software-Practice and Experience, Vol. 23(11) P. 1249-1265 (November 1993). This algorithm offers n*log(n) performance on many data sets that cause other quicksorts to degrade to quadratic performance.”

  32. XawSport:

    : Ну нет же!

    The sorting algorithm is a modified mergesort (in which the merge is omitted if the highest element in the low sublist is less than the lowest element in the high sublist). This algorithm offers guaranteed n log(n) performance. This implementation dumps the specified list into an array, sorts the array, and iterates over the list resetting each element from the corresponding position in the array. This avoids the n2 log(n) performance that would result from attempting to sort a linked list in place.

  33. XawSport:

    : Ок, насчёт публичного класса, пожалуй, соглашусь, хотя в SDK встречаются такие решения. Например, java.util.HashMap#hash – метод используется как HashMap, так и в WeakHashMap, который находится в том же пакете. В принципе, они могли завести какой-нибудь HashMapUtils с дефолтной видимостью для этих целей. Вообще говоря, интересный вопрос. Надо поискать какие-то аргументы в пользу таких методов в публичных классах.

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

  34. XawSport:

    : вполне возможно, что изначально использовался именно quick sort, а потом от него отказались из-за его нестабильности.

  35. NieTunes:

    : Теперь понял где у нас расхождения, мердж сорт в Collections, а я про Arrays писал:)

  36. XawSport:

    : круто! спасибо, буду знать теперь 🙂

  37. XawSport:

    : кстати, любопытно то, что quick sort применяется только для числовых массивов (byte, short, int, long, float, double), а для массивов объектов, опять-таки, применяется merge sort. Видимо, это связано с особенностями реализации сортировки.

  38. Ovenode:

    : э ну это наверное как раз из за нестабильности, какая разница как инты сортировать.

  39. Aklre:

    : класс, однозначно, да. поле в классе, по возможности нет. метод в публичном классе – лучше всего избежать. hash во-первых статический (нет проблемы с перегрузкой), во-вторых почему WeakHashMap должен зависеть от HashMap изза этого метода? я знаю, что у моего соседа есть дрель, поэтому себе покупать не буду. да, его лучше было унести в утиль или даже защищённым в базовый класс.

  40. XawSport:

    : да, здесь так и пишут.

  41. NieTunes:

    : Я тоже благодаря этому посту много нового для себя узнал:)

  42. NieTunes:

    :
    Ага, спасибо.
    Кроме канкаренси, по которому у меня только прочитанная год назад “java concurrency in practice” вроде все более или менее ок.

  43. XawSport:

    : я убежден в том, что если книга Java Concurrency in Practice прочитана и усвоена хотя бы на 80 процентов, на вопросы, относящиеся к многопоточности, на подавляющем большинстве собеседований можно ответить без особого труда. Эта книга – безусловный мастрид.

  44. Hctwin:

    : Про синтаксис все-таки спрашивают, например про особенности работы instanceof. Чего мы заплатим за instanceof? A может try{ } catch (ClassCastException ex){}, вдруг так быстрее, если ошибка практический исключена?

    Также не забывают спросить про public, private, protected, package ну и try/catch/finally.

    Когда достаточно/необходимо volatile, а когда нам нужен synchronized. Synchronized весь метод или блок? Atomic – ААА, что это? Вы знаете атомики!, а слабо ReentrantLock vs synchronized;

    Коллекции. А как хранятся данные в той или иной коллекции? Не знаете?, ну давайте придумывать исходя из того, что мы про нее знаем.

    Меня один раз спрашивали про тот, как организовано хранение отрицательных чисел в java.

    Самый лучший способ понять знает ли человек ЯП – это посмотреть на его код. Многие вещи человек не может знать, например исходя из того, что ему оно особо не встречалась. Например при разработке web приложений работа с потоками минимальна. А при разработке десктоп приложений мала вероятность встретить хибернейт. При этом разобраться и в том и в другом можно довольно быстро.
    Я не понимаю позицию людей, которые берут на работу исключительно тех, кто знает все. Я считаю нормальным взять человека на испытательный срок чтобы посмотреть насколько быстро и качественно он заполняет пробелы в своих знаниях. Даже если из 10 человек окажутся только 1-2 хороших специалистов, в плане финансовых потерь для фирмы это ничто. Да и остальные 8 не все уйдут, из кого-то может получится аналитик/тестер/писатель или кто-то еще.

  45. XawSport:

    : ну, про instanceof – это, всё-таки, не синтаксис, а семантика уже.

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

  46. Hctwin:

    : А почему вы тогда тратите время кандидата и не пишете о том, что у вас ТДД заместо корпоративной религии прямо в самой вакансии?
    Мне кажется, что это не самый удачный пример того, что может стать причиной отказа кандидату после практической части собеседования.
    Я понимаю, если бы в коде нарисовалось что-то вроде:
    Collection c = …
    for(int i = 0; i < c.size() ; i++ ) {
    А в резюме 5+ лет опыта. *Кстати, это реальный пример.

    Или еще какие-то хитросплетения патернов, алгоритмов и подходов. Но ни как не отношение к ТДД, о котором заходит речь только на практическом этапе собеседования.

  47. Aklre:

    : TDD – зло. не холивор, дорого.

  48. XawSport:

    : какие ваши доказательства?

  49. XawSport:

    : Не, минуточку. Давайте разберёмся. Во-первых, в вакансии про TDD было, во-вторых, удивительно, но многие люди думают, что TDD – это когда тесты пишут. Или это когда тесты пишут, но сразу много-много тестов, а потом уже код. Разумеется, это было не единственной причиной, хотя и одной из основных. У нас тут XP в полный рост – парное программирование и TDD, а человек привык одиноким ковбоем в прериях, а на принципы, описанные в Clean code, если и не клал болт, то уж по крайней мере имеет своё видение. В какой-то момент выполнения практического задания стало очевидно, что в человек в существующий процесс не впишется. Так бывает, увы.

    Это было вообще очень досадно, когда менеджер отказал тому человеку, и мы настояли на 3-м собеседовании, тоже практическом, на котором этот человек сам нас только что нахуй не послал с этим нашим TDD. Оно закончилось через 20 минут по его инициативе.

  50. Hctwin:

    : а вариант научить человека этому подходу вы не рассматриваете? неужели кандидат вам открытым текстом говорит, что ТДД он терпеть не может и использовать не будет? Может на его предыдущем месте работе был другой подход к написанию кода и ТДД для него просто непривычно.
    Я просто сторонник того, что пробелы в знаниях не повод не брать человека на работу, а отсутствие опыта использования ТДД уж подавно.
    Описанное в последнем абзаце – клинический случай, и ну его нахуй.

  51. KoZlo:

    : ну вот если ты не просто о “написании тестов к коду”, а к довольно безумной практике “сначала тест, потом код, и никакого кода без специального рушащегося теста”, то она бывает довольно медленной (особенно с непривычки, или если тестировать тяжело поставленную задачу); порою приводит к довольно странной архитектуре; не очень хорошо позволяет исследовать problem domain (ну в смысле поиграться в shell тебе никто не запретит, но сделать из этих наиграний библиотечку или что-то в этом роде не разрешает оно так сходу) и вообще “поисследовать разные пути решения задачи” это нечто за рамками TDD

    не уверен, что этих аргументов хватит на “зло” (потому что все равно все и так медленно программируют, архитектура и так у всех хуевая, и исследовать что-то всем и так нахуй не всралось), но сказать, что это не панацея и не идеал уже можно

  52. Aklre:

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

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

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

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

    тдд не панацея и не уверен, что его оверхед стоит того отнюдь не стопроцентного уровня надёжности.

  53. Lagapp:

    : > я сторонник строгой типизации и если в модели исчезает поле, то такой код просто должен переставать компилироваться.

    Ну собственно это и объясняет большую популярность TDD в среде разного рода рубистов и питонщиков. Хотя, конечно, строгость типизации не спасает от некоторых, гхм, просчётов в дизайне языков (привет, NullPointerException, ололо).

  54. Hctwin:

    : я вот обычно начинаю писать код с тестов хотябы потому, что компилировать весь проект для отладки одного модуля просто не реально. Те фактический тест изначально это просто точка начала исполнения кода.
    После этого можно экспериментировать сколько угодно. Можно строить юмл диаграммы, делать наброски классов, сверяться с моделью хранения данных в БД, и делать много других полезных и не очень вещей, до тех пор пока не начнет прорисовываться структура модуля.
    Потом удаляется все ненужное и начинается писаться сам тест, а за ним и код.

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

  55. Hctwin:

    : NullPointerException – это косяк программиста и смысла писать на него тест я не вижу. Все что используется в методе либо должно проверяться на null, либо должно быть константой.
    Представить третий вариант мне не удалось. Особенное такой, который можно покрыть тестом.

  56. Aklre:

    : то есть тесты нужно писать прагматично а не потому что методология их требует? с этим соглашусь.

    и каждый решает какая степень прагматичности для него осмысленна.

  57. Nasgreen:

    : прикольно, спасибо.

  58. Erobad:

    : А формальная верификация – не дорого? тем не менее её используют. так что это не аргумент.

  59. Nasgreen:

    : так как раз и пишут, что никак. Или я что-то не понял.

  60. Aklre:

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

  61. 0duaTa:

    : To avoid GC you simply need to make sure not to allocate memory after the startup and warm-up phase of your application

  62. Nasgreen:

    : я в том смысле, что никак нельзя, есть какие-то техники, как типа сделать так, чтоб он не вызвался, но это, типа, анрил, если только не использовать никаких библиотек, в том числе строк.

  63. XawSport:

    : Можно. Уж не знаю, чего там в гугле пишут, но в DB есть высоконагруженная торговая платформа для FX-а, в которой major GC запускается раз в день, в то время как minor GC работает считанные миллисекунды, которые практически не влияют на работу платформы.

  64. XawSport:

    : Практика эта ничуть не безумна. В ней есть очень чёткий практический смысл. Во-первых, если ей следовать, то можно быть уверенным в том, что код не делает ничего такого, что не проверяет тест. Когда тесты пишутся потом, после кода, как понять, что пора остановиться? И, что более важно, как заставить себя написать тесты, которые покрывают весь код? Лениво же.

    Во-вторых, TDD форсит некоторые очень правильные архитектурные принципы, такие, как SRP или YAGNI. Плохой код неудобно тестировать, и это вполне чёткий сигнал для того, что надо подумать о том, как бы его зарефакторить.

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

    Исследование problem domain и разных путей решения задачи вообще ортогонально TDD, никаких противоречий я тут не вижу.

    Подытоживая, скажу, что не считаю TDD какой-то панацеей или безусловным идеалом, однако у меня есть опыт работы с ним и без него, и могу с уверенностью сказать, что работа по TDD получается эффективнее.

  65. XawSport:

    :

    тдд подразумевает правильную и окончательную архитектуру вплоть до классов до начала написания собственно кода.

    Вас кто-то обманул. Вот статья про TDD. Гляньте, пожалуйста. Там нет ни слова про окончательную архитектуру. Как вы себе представляете Agile-разработку, одним из краеугольных камней которых является TDD, в которой “сначала разрабатывается архитектура”. Это же абсурд, agile ровно про обратное.

    TDD наоборот подразумевает итеративную разработку малыми шагами, класс за классом, метод за методом, которые добавляются по мере необходимости, а не тогда, когда левая пятка архитектора так захотела.

    Все эти разговоры типа “стоит ли метод сделать публичным” говорят об отсутствии правильного понимания TDD и неправильном его применении. Тест “вернул ли контроллер модель с полем ХХХ” очевидно крив, потому что нарушаетcя инкапсуляция.

    то есть тех пяти кейсов, что я придумал, оказалось не достаточно.
    Это не TDD. Когда код пишется по TDD, юзкейсы не надо придумывать.

    Как я уже говорил, есть масса способов выстрелить себе в ногу, но ружьё в этом ничуть не виновато.

  66. XawSport:

    : Последний абзац был про miscommunication. Человек на втором собеседовании явно показал несогласие с предъявляемыми требованиями и совершенно не понял, зачем его позвали на третье. Ну да, ладно, досадно, но бывает.

    Вариант “научить человека” мы, безусловно, рассматриваем. Умение работать по TDD – это лишь один из критериев годности. Такого же веса примерно, как и знание Spring или Hibernate. Если нужное количество условных очков набирается, то кандидат проходит. Обучение на работе – это клёво, конечно, но нам бы на всё готовенькое. Поэтому очень хочется, чтобы пробелов было по-минимуму.

  67. 0duaTa:

    : а где сказал, что можно?
    > no–gc setup — когда вся куча при старте программы выделяется и руками рулится

  68. Nasgreen:

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

  69. XawSport:

    : ну совсем, может быть, нельзя, но свести его эффект к минимуму можно. Проблема ведь не в том, что GC работает, а в stop-the-world, который необходимо выполнить в процессе. В альтернативном JVM под названием Azul вообще, говорят сборщик мусора паузу не требует.

  70. Aklre:

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

    из статьи: Не существует единого мнения среди программистов, применяющих разработку через тестирование, о том, насколько это осмысленно тестировать private – и protected-методы и данные.

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

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

  71. Erobad:

    : согласен. догматы нужно отстреливать

  72. Lagapp:

    : Aux, перелогиньтесь

  73. NinAll:

    : а что плохого в таком for? Кроме того, что можно for (int i = 0, sz = c.size();…)?

  74. Hctwin:

    : можно запутаться с i и взять не тот элемент. и вообще много букав.
    Collection c = …
    for(Object o : c) {

  75. Hctwin:

    : в реальной жизни
    List list = …
    for(String s : list) {
    выглядит приятнее, imho

  76. Hctwin:

    : еще можно так
    for(Iterator i = list.iterator(); i.hasNext(); ) {
    System.out.println(i.next());
    }
    но есть вероятность вызвать 2 раза i.next() и будет плохо

    аналогично с
    Iterator i = list.iterator();
    while (i.hasNext) {
    System.out.println(i.next());
    }

  77. NinAll:

    : тут неявно создается итератор, и т.к. jvm еще не научилась класть его на стек – после выполнения будет мусор. Вон, в гуаве баг на эту тему есть.
    Я к тому, что может человек подумал хорошо перед ответом, а о нем подумали не очень.

  78. NinAll:

    : ой, это все относится к ArrayList, а не к Collection конечно же.

  79. OtsFcuk:

    : а если это linked list окажется?

  80. OtsFcuk:

    : где-где, в пи^Wв Scala. Разве что кроме IDisposable.

Добавить комментарий