Здравствуйте, Steamus, Вы писали:
S>По поводу работы стандартных коллекций с примитивными типами. Не знаю что сказать. Сходу не смог вспомнить когда мне последний раз приходилось заталкивать неизвестное количество примитивных типов в ArrayList. Учитывая что работаю я давно и плотно, видимо не такая уж и критичная вещь. Обычно размер известен и проще использовать обычный массив.
Вы не поняли про, что я говорил. Повторю ещё раз, в C# есть такая вещь, как структура тот же класс (без возможности наследовать классы/структуры) только размещается не в куче, а на стеке и является типом значения. В Java такого нет, там только классы и размещаются в куче. В C# дженерики реализованы на уровне CLR и помещая структуру в коллекцию она не упаковывается.
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, Steamus, Вы писали:
S>>По поводу работы стандартных коллекций с примитивными типами. Не знаю что сказать. Сходу не смог вспомнить когда мне последний раз приходилось заталкивать неизвестное количество примитивных типов в ArrayList. Учитывая что работаю я давно и плотно, видимо не такая уж и критичная вещь. Обычно размер известен и проще использовать обычный массив.
S>Вы не поняли про, что я говорил. Повторю ещё раз, в C# есть такая вещь, как структура тот же класс (без возможности наследовать классы/структуры) только размещается не в куче, а на стеке и является типом значения. В Java такого нет, там только классы и размещаются в куче. В C# дженерики реализованы на уровне CLR и помещая структуру в коллекцию она не упаковывается.
S>А массив в java является объектом, если что...
Да, я действительно "не понимаю" о чём Вы говорите. Большинство этих вещей решаются архитектурно и тонким местом не являются. Дискуссия на тему что можно создать на стеке а что в куче, напоминает мне дискуссии из махровых девяностых. Сишники постоянно кусали Сиплюсплюшников не предмет того — а вот ваша VMT занимает целых три бита места в памяти.
В C# дженерики действительно реализованы лучше и помещая структуру в коллекцию она не упаковывается. Ну и хорошо. В том одном десятом процента случаев когда это будет действительно критично, подумаю что с этим сделать.
Здравствуйте, Steamus, Вы писали:
S>Да, я действительно "не понимаю" о чём Вы говорите. Большинство этих вещей решаются архитектурно и тонким местом не являются. Дискуссия на тему что можно создать на стеке а что в куче, напоминает мне дискуссии из махровых девяностых. Сишники постоянно кусали Сиплюсплюшников не предмет того — а вот ваша VMT занимает целых три бита места в памяти.
Вот, что java с программистами делает))
Совет, прочитайте вот это
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, Steamus, Вы писали:
S>Совет, прочитайте вот это
Неплохой текст, но длинный. Освоил половину. Понравилась фраза: "Java в целом недостаточно сложна, чтобы отделить отличных программистов от посредственных." Это так. Джоел С. имеет достаточно тараканов в мозгу. Факт известный. Пишет тексты гладко и весело. Часто пишет глупости, но художественно и читабельно.
Здравствуйте, sysenter, Вы писали:
S>А массив в java является объектом, если что...
PS: А что с того, что массив является оъектом?! Ну завернули ребята это в класс. Абсолютно правильно. Удобно. Или вы полагаете, что они теперь внутри используют стандартные списки/коллекции, с боксингом примитивных типов в непримитивные и интенсивным использованием кучи?
Здравствуйте, vsb, Вы писали:
С>>>Шарп — платформо-зависисмый и к тому же MS зависимый. Чего не скажешь о джаве. AK>>Она уже Oracle-зависима. vsb>В чём это выражается?
Например, в попытках кошмарить Android-ориентированный бизнес, в препирательствах по поводу Java Technology Compatibility Kit.
Я не сильно слежу за этой темой, но когда я подумывал перелезть с С++ на Java, деятельность Oracle показалась мне направленной на развал платформы Java.
Здравствуйте, Steamus, Вы писали:
С>>>Шарп — платформо-зависисмый и к тому же MS зависимый. Чего не скажешь о джаве. AK>>Она уже Oracle-зависима. S>Oracle это не операционная система. И БД Oracle работает в среде большинства OS. Таким образом для Oracle крайне важна хорошая переносимость Java платформы.
Я имел в виду не платформо-зависимость, а зависимость развития Java от действий Oracle.
С платформо-независимостью у Java пока вроде всё хорошо.
Здравствуйте, Artem Korneev, Вы писали:
AK>Здравствуйте, vsb, Вы писали:
С>>>>Шарп — платформо-зависисмый и к тому же MS зависимый. Чего не скажешь о джаве. AK>>>Она уже Oracle-зависима. vsb>>В чём это выражается?
AK>Например, в попытках кошмарить Android-ориентированный бизнес, в препирательствах по поводу Java Technology Compatibility Kit. AK>Я не сильно слежу за этой темой, но когда я подумывал перелезть с С++ на Java, деятельность Oracle показалась мне направленной на развал платформы Java.
Вы лучше предварительно следите таки за темой. Сами быстро поймёте, что вы сейчас сказали.
Здравствуйте, Steamus, Вы писали:
S>>Вы не поняли про, что я говорил. Повторю ещё раз, в C# есть такая вещь, как структура тот же класс (без возможности наследовать классы/структуры) только размещается не в куче, а на стеке и является типом значения. В Java такого нет, там только классы и размещаются в куче. S>Да, я действительно "не понимаю" о чём Вы говорите. Большинство этих вещей решаются архитектурно
Оборачиванием структуры в паттерн стратегия?
Как человек работавший достаточно долгое время с двумя платформами могу сказать следующее:
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, Steamus, Вы писали:
S>>Вот никогда умом не мог понять почему Шарп/Дотнет технически более привлекателен
S>Курите матчасть. S>Реализация дженериков в Java это фикция, в дотнете это сделано на уровне CLR.
Да дженерики в Java "ненастоящие" но и эти весьма неплохи. Свою основную роль они выполняют.
S>В дотнете есть структуры которые являются типами размещаемыми на стеке, как int например. А в Java всё объект кроме byte, short, int, long, float, double, char, bool.
Зато в JVM есть escape-анализ который может определить нужно ли создалвать объект в куче или в стеке.
S>Такие вещи, как Linq и boxing изначально появились в дотнете и только потом мигрировали в Java, это к вопросу кто у кого тырит. Реализовать же Linq прозрачно в JVM невозможно в силу тех.ограничености JVM.
Linq — тормознутая хрень и нужна разве что для мелких десктопных проектов. В enterprise-приложениях а это основной профиль Java, такие вещи просто не нужны.
S>Методы расширения очень интересная вещь, возможность работы с указателями, возможность работы с нативным кодом и т.д. и т.п. S>В Java этого или нет или сделано через ж...
Опять повторюсь — для enterprise-приложений это все ненужно абсолютно. Дешевле поставить еще пару серверов чем пытаться оптимизировать еще 10% играясь с указателями.
S>>Да, можно говорить о том, что в Шарп внесены некоторые продвинутые (и усложняющие) вещи, которые джава не может себе легко позволить в силу серъёзной ответственности перед корпоративным рынком, но которые очень нравятся пользовать молодым любителям витиеватого кода в силу того, что за плечами ещё не висит тяжёлый груз реализованных систем.
S>Т.е. накладные расходы на упаковку/распаковку примитивных типов при помещении в ArrayList это фишка для любителей витиеватого кода? Стоит ли понимать ваши слова так, что в силу серьёзной ответственности перед корпоративным рынком Java должна обязательно тормозить и кушать память?
S>>Но, ведь помимо языка существуют технологии, окружающие платформу. И такого количества интересных библиотек/фреймворков которое несёт джава, дотнету даже близко не снилось. Спринги, хибернейты, хедопы всё это из мира джава. И лишь позже мигрируют в Нет. Про веб даже вспоминать смысла нет. В шарпе есть фреймворк номер 1 и номер 2. Всё. А основная человеческая мысль пульсирует в джава мире.
S>А кто спорит, что фреймворков больше, но если фрейворки крутятся на VM которая примитивные типы всегда упаковывает при помещении в коллекцию это просто абзац...
Вот не помню когда мне нужно было хоть раз иметь коллекцию примитивов.
S>>на джава машине/платформе работают такие интересные языки как Scala, Groovy, Clojure, JRuby, JPython (Jython), Kotlin, Rhino, Ceylon...
S>Под .Net тоже языков немеряно, вот у нас в проекте IronPython помимо C# используется и что? Такая куча языков мне лично не нужна, мне хватает C++/C#. Нет, если конечно вы каждую неделю предпочитаете писать на новом языке то вопрос нет.
S>>Всё интересное что приходит в человеческую голову находит своё отражение в джава мире. И при этом имеет доступ ко всем библиотекам платформы. И всё это для всех операционных систем.
S>Кто-то с этим спорит? Так происходит потому, что MS веры нет. Но в силу перечисленных выше вещей .Net более технически развит.
Дело не в вере а в том что да .Net более развита с академической точки зрения но на практике для enterprise-приложений Java платформа будет лучше. И да, пресловутая независимость от ОСи все же играет огромную роль (вот только не надо мне говорить про Моно). Вот не разу не видел чтобы большая распределенная система работала под MS Server.
Вобщем то этот холивар может продолжаться сколько угодно.
Здравствуйте, -VladK-, Вы писали:
VK>Зато в JVM есть escape-анализ который может определить нужно ли создалвать объект в куче или в стеке.
Который по умолчанию выключен и который на x86_64 в купе с другими опциями для тюнинга иногда роняет JVM.
VK>Linq — тормознутая хрень и нужна разве что для мелких десктопных проектов. В enterprise-приложениях а это основной профиль Java, такие вещи просто не нужны.
Если этого нет в Java значит это тормознутая хрень которая не нужна. Окей, понял)
S>>Методы расширения очень интересная вещь, возможность работы с указателями, возможность работы с нативным кодом и т.д. и т.п. S>>В Java этого или нет или сделано через ж...
VK>Опять повторюсь — для enterprise-приложений это все ненужно абсолютно. Дешевле поставить еще пару серверов чем пытаться оптимизировать еще 10% играясь с указателями.
Вы делаете мне смешно))
VK>Вот не помню когда мне нужно было хоть раз иметь коллекцию примитивов.
Ещё раз повторяю, в C# структура есть тип значение размещаемое на стеке и я могу без boxing/unboxing наполнить коллекцию структурами.
В Java во первых нужно включить escape анализ через -XX:-DoEscapeAnalysis (а эта опция из разряда опасных), потом наполнить коллекцию классами над которыми произойдёт boxing и только потом через 10000 для -client и 1500 для -server обращений к этому участку кода, код будет обработан JIT который накопит статистику для выполнения оптимизаций кода включая escape оптимизацию.
Здравствуйте, sysenter, Вы писали:
S>Ещё раз повторяю, в C# структура есть тип значение размещаемое на стеке и я могу без boxing/unboxing наполнить коллекцию структурами. S>В Java во первых нужно включить escape анализ через -XX:-DoEscapeAnalysis (а эта опция из разряда опасных), потом наполнить коллекцию классами над которыми произойдёт boxing и только потом через 10000 для -client и 1500 для -server обращений к этому участку кода, код будет обработан JIT который накопит статистику для выполнения оптимизаций кода включая escape оптимизацию.
в выделеном я имел ввиду, что произошёл бы boxing если бы в Java был аналог структур из C# + примитивы понятное дело в Java подвергаются боксингу.
Здравствуйте, sysenter, Вы писали:
VK>>Зато в JVM есть escape-анализ который может определить нужно ли создалвать объект в куче или в стеке. S>Который по умолчанию выключен и который на x86_64 в купе с другими опциями для тюнинга иногда роняет JVM.
дополнение: ескейп анализ это вроде, как только в Sun/Oracle JVM, ну и возможно ещё в IBM JVM, а в OpenJDK его нет.
Предлагаете привязаться к определённому вендору JVM?)
Здравствуйте, -VladK-, Вы писали:
VK>Linq — тормознутая хрень и нужна разве что для мелких десктопных проектов. В enterprise-приложениях а это основной профиль Java, такие вещи просто не нужны.
S>> возможность работы с указателями, возможность работы с нативным кодом и т.д. и т.п.
VK>Опять повторюсь — для enterprise-приложений это все ненужно абсолютно. Дешевле поставить еще пару серверов чем пытаться оптимизировать еще 10% играясь с указателями.
Взаимоисключающие параграфы детектед. LINQ — тормознутая хрень, поэтому не нужен. Работа с указателями не нужна — потому что добавим сервера.
А для LINQ'а сервера добавлять не комильфо?
Здравствуйте, sysenter, Вы писали:
S>Который по умолчанию выключен и который на x86_64 в купе с другими опциями для тюнинга иногда роняет JVM. S>В Java во первых нужно включить escape анализ через -XX:-DoEscapeAnalysis (а эта опция из разряда опасных), потом наполнить коллекцию классами над которыми произойдёт boxing и только потом через 10000 для -client и 1500 для -server обращений к этому участку кода, код будет обработан JIT который накопит статистику для выполнения оптимизаций кода включая escape оптимизацию.
Мужики, вы взаправду всё это одновременное гамно в голове держите, или тупо для этой дискуссии штудировали?
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, -VladK-, Вы писали:
VK>>Зато в JVM есть escape-анализ который может определить нужно ли создалвать объект в куче или в стеке.
S>Который по умолчанию выключен и который на x86_64 в купе с другими опциями для тюнинга иногда роняет JVM.
Все нормально работает в последних версиях.
VK>>Linq — тормознутая хрень и нужна разве что для мелких десктопных проектов. В enterprise-приложениях а это основной профиль Java, такие вещи просто не нужны.
S>Если этого нет в Java значит это тормознутая хрень которая не нужна. Окей, понял)
Не критична для определенного круга приложений.
S>>>Методы расширения очень интересная вещь, возможность работы с указателями, возможность работы с нативным кодом и т.д. и т.п. S>>>В Java этого или нет или сделано через ж...
VK>>Опять повторюсь — для enterprise-приложений это все ненужно абсолютно. Дешевле поставить еще пару серверов чем пытаться оптимизировать еще 10% играясь с указателями.
S>Вы делаете мне смешно))
Рад приносить людям радость.
VK>>Вот не помню когда мне нужно было хоть раз иметь коллекцию примитивов.
S>Ещё раз повторяю, в C# структура есть тип значение размещаемое на стеке и я могу без boxing/unboxing наполнить коллекцию структурами. S>В Java во первых нужно включить escape анализ через -XX:-DoEscapeAnalysis (а эта опция из разряда опасных), потом наполнить коллекцию классами над которыми произойдёт boxing и только потом через 10000 для -client и 1500 для -server обращений к этому участку кода, код будет обработан JIT который накопит статистику для выполнения оптимизаций кода включая escape оптимизацию.
Вы что пытаетесь мне доказать — что .Net в определенных местах лучше ? Так я с этим и не спорю. Я сам так считаю. Неудивительно для технологиии которая появилась позже и должна была учесть все недостатки того конкурентом чему она призвана быть.
Вы упорно указываете на вещи которые для определенного круга задач с точки зрения бизнеса не важны. А именно бизнес и рынок выбирает технологию.
Здравствуйте, sysenter, Вы писали:
S>Здравствуйте, sysenter, Вы писали:
VK>>>Зато в JVM есть escape-анализ который может определить нужно ли создалвать объект в куче или в стеке. S>>Который по умолчанию выключен и который на x86_64 в купе с другими опциями для тюнинга иногда роняет JVM.
S>дополнение: ескейп анализ это вроде, как только в Sun/Oracle JVM, ну и возможно ещё в IBM JVM, а в OpenJDK его нет. S>Предлагаете привязаться к определённому вендору JVM?)
Найдите мне хоть одно приложение для которого наличие этой фичи критично.
И еще — вы много знаете на рынке продуктов продуктов которым важно работать на не Sun/Oracle JVM ?
Здравствуйте, -VladK-, Вы писали:
VK>Вы что пытаетесь мне доказать — что .Net в определенных местах лучше ? Так я с этим и не спорю. Я сам так считаю. Неудивительно для технологиии которая появилась позже и должна была учесть все недостатки того конкурентом чему она призвана быть.
Что печально, она (.NET) учла ровно два недостатка (структуры и генерики) своего прототипа (Java), зато наплодила своих собственных.
