Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 160
Ораклы становятся как эппл?
Я вот что-то не припомню подобных исков от гугла к кому-либо. Или не прав?
Я вот что-то не припомню подобных исков от гугла к кому-либо. Или не прав?
До Apple им как до Луны.
Андроид — это ОС, которая сильно способствует развитию Java сегодня.
И подобные иски от Оракл, это как рубить сук, на котором сидишь.
Андроид — это ОС, которая сильно способствует развитию Java сегодня.
И подобные иски от Оракл, это как рубить сук, на котором сидишь.
Популяризует среди узких кругов — возможно.
Но по поводу «сильно способствует развитию»… я бы поспорил.
Может поделитесь конкретными данными, чего там Андроид наразвивал в Java??
Но по поводу «сильно способствует развитию»… я бы поспорил.
Может поделитесь конкретными данными, чего там Андроид наразвивал в Java??
Я даже не знаю, как комментировать словами взгляды хаброшкольников, поэтому сделаю вот так:
www.tiobe.com/index.php/content/paperinfo/tpci/index.html
www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Если вы прочитаете комментарий, на который отвечаете, внимательнее, то заметите, что это ваше «количество разработчиков»(читай популярность языка среди разработчиков) было уже отмечено! Зачем об этом еще раз говорить??
Я про «сильно способствует развитию Java сегодня» вообще-то спросил. Раз уж вы стали за автора аругменты приводить — будьте добры конкретику.
Мы тут на Java последние лет 8 пишем и не понимаем, что с ней случилось благодаря появлению Андроида.
>>«23 сентября 2008 года официально вышла первая версия операционной системы»
что случилось с JDK/JVM/whatever с тех пор Б Л А Г О Д А Р Я этому вашему Андроиду?
Я про «сильно способствует развитию Java сегодня» вообще-то спросил. Раз уж вы стали за автора аругменты приводить — будьте добры конкретику.
Мы тут на Java последние лет 8 пишем и не понимаем, что с ней случилось благодаря появлению Андроида.
>>«23 сентября 2008 года официально вышла первая версия операционной системы»
что случилось с JDK/JVM/whatever с тех пор Б Л А Г О Д А Р Я этому вашему Андроиду?
> Б Л А Г О Д А Р Я этому вашему Андроиду?
Благодаря андроиду java не превратилась в забытые всеми фекалии мамонта. Конечно у нее бы оставалась своя ниша и без андроида, но C# очень на пятки наступает по всем фронтам, при том, что C# как язык уже обгоняет в своем развитии яву года на 3.
Там где не нужна кроссплатформенность и винда сойдет за операционку — с вероятность 99% для разработки будет выбран .net для новых проектов.
Благодаря андроиду java не превратилась в забытые всеми фекалии мамонта. Конечно у нее бы оставалась своя ниша и без андроида, но C# очень на пятки наступает по всем фронтам, при том, что C# как язык уже обгоняет в своем развитии яву года на 3.
Там где не нужна кроссплатформенность и винда сойдет за операционку — с вероятность 99% для разработки будет выбран .net для новых проектов.
ЩИТО?
Это как же, интересно, Андроид способствует развитию Java? Потрудитесь объяснить свои слова, пожалуйста.
Это как же, интересно, Андроид способствует развитию Java? Потрудитесь объяснить свои слова, пожалуйста.
Все просто, Гугль ведь корпорация добра, вот их судебные иски не привлекают такого внимания. Были у них суды, например к тем же apple по поводу siri, были иски по поводу поисковых алгоритмов и контекстной рекламе.
Да и жуткость патентных тяжб Эппл сильно преувеличена, на слуху громкое дело с Самсунгом (а там скорее плагиат чем патенты, хоть те и пытались прикинуться шлангом и сделать вид что их несправедливо обидели за «прямоугольник с закругленными углами»).
Да и жуткость патентных тяжб Эппл сильно преувеличена, на слуху громкое дело с Самсунгом (а там скорее плагиат чем патенты, хоть те и пытались прикинуться шлангом и сделать вид что их несправедливо обидели за «прямоугольник с закругленными углами»).
вот их судебные иски не привлекают такого внимания
Привлекают, но в подавляющем числе иски Google — это countersuit, а не suit. Единственный suit по патентам с Android Google вела против Apple, и то потому, что этот suit достался по наследству от поглощённой Motorola Mobility, которая его получила по наследству от Motorola.
Решение суда по сути отменяет предыдущий вердикт Алсупа о том, что API не подлежат защите авторским правом. Апелляционный суд решил наоборот, поэтому теперь будет второй раунд разборок Oracle vs. Google.
По патентам Oracle проиграла полностью и без вариантов, так что останутся вопросы по API и rangeCheck, но Google скорее всего будет давить на fair use. По большому счёту Google это намеревалась делать и в суде, в котором заседал Алсуп, но он внезапно посчитал, что рассматривать нечего, так как Oracle гонит, и до fair use толком дело и не дошло.
Ну а вообще, как я понимаю, это решение ещё может быть обжаловано.
По патентам Oracle проиграла полностью и без вариантов, так что останутся вопросы по API и rangeCheck, но Google скорее всего будет давить на fair use. По большому счёту Google это намеревалась делать и в суде, в котором заседал Алсуп, но он внезапно посчитал, что рассматривать нечего, так как Oracle гонит, и до fair use толком дело и не дошло.
Ну а вообще, как я понимаю, это решение ещё может быть обжаловано.
Имеются в виду интерфейсы Java — да, можно сказать сигнатуры методов и классов. Без их использования версии Java будут несовместимы между собой.
Можете почитать статьи по запросу «Oracle Android», на хабре уже многое писали: одна (Алсуп разносит Oracle), вторая (о строках кода), третья (опасности претензий Oracle для Open Source), четвёртая (уход из Oracle Гослинга, создателя Java).
Можете почитать статьи по запросу «Oracle Android», на хабре уже многое писали: одна (Алсуп разносит Oracle), вторая (о строках кода), третья (опасности претензий Oracle для Open Source), четвёртая (уход из Oracle Гослинга, создателя Java).
Давить можно, когда есть вероятность получить что-то взамен. Google — достаточно большая корпорация, чтобы заплатить 1 млрд долларов, а вот создатели проекта Mono… сомневаюсь :)
Microsoft гарантирует, что не будет подавать в суд на разработчиков любых альтернативных реализаций С#.
>>но больше работать с ораклоидными продуктами желания никакого нет
Никогда не понимал таких людей. Пишешь 5 лет на Java, а после судебного разбирательства с гуглом все бросаешь, и идешь работать дворником. Или вы только в интернете такой?
Никогда не понимал таких людей. Пишешь 5 лет на Java, а после судебного разбирательства с гуглом все бросаешь, и идешь работать дворником. Или вы только в интернете такой?
И все от того что юристы Oracle прощелкали клювом, с судьей. Любому нормальному технарю понятно, что это бред. Из-за этого Oracle активно давил, чтобы их не было в присяжных.
Интересно, на эту сумму они сделают хоть что-то, что заставит Java работать более стабильно, не выжирая всю доступную память…
Самое лучшее, что можно сделать, чтобы Java работала более стабильно, не выжирая всю доступную память — это уволить пару десятков тысяч дилетантов, которые не умеют ей пользоваться и пишут на хорошо спроектированном языке чёрт знает что чёрт знает как. Увы, чем ниже порог вхождения языка (а у Java он чрезвычайно низок), тем больше людей, работающих по принципу «как-нибудь тяп-ляп напишем, лишь бы работало»
А новость ужасная, конечно…
А новость ужасная, конечно…
Самое лучшее, что можно сделать, чтобы Java работала более стабильно, не выжирая всю доступную память — это уволить пару десятков тысяч дилетантов, которые не умеют ей пользоваться и пишут на хорошо спроектированном языке чёрт знает что чёрт знает как.
О да! Когда зовут разобраться с проблемами с производительностью в тривиальном проекте на Java. И ты видишь, что для отображения страницы с четырмя графиками и тремя списками совершается почти 600 (это не опечатка — шесть сотен) sql запросов. Хочется КРОВИ!!!
Это что — для каждой точки на графике и для каждой строки в списке по запросику?
Некоторые вещи даже не стоит пытаться понять и простить ;)
Там бездумное использование ORM.
Там бездумное использование ORM.
ORM, на мой скромный взгляд, вообще зло. Наблюдал, как люди (опытные и хорошо разбирающиеся в теме) с его помощью организовали код очень большого и сложного проекта. И проект этот начал страшно тормозить, несмотря на то, что ничего критичного по производительности не делал. В результате пришлось половину кода уровня сервисов переделывать и впиливать-таки прямые SQL-запросы, что, конечно, ускорило работу приложения в разы, но создало кривобокую архитектуру и конфликтные ситуации между автоматически сгенерированным SQL и написанным вручную.
Сам я по базам данных не спец (почти ни с чем серьёзней SQLite не работал), но запросы предпочитаю писать сам — так, по крайней мере, понятно, что как делается.
Скажу банальную вещь: чем сложнее и интеллектуальней устроена система, тем больше шансов, что ее подстройка под нестандартную ситуацию выльется в кошмар.
Сам я по базам данных не спец (почти ни с чем серьёзней SQLite не работал), но запросы предпочитаю писать сам — так, по крайней мере, понятно, что как делается.
Скажу банальную вещь: чем сложнее и интеллектуальней устроена система, тем больше шансов, что ее подстройка под нестандартную ситуацию выльется в кошмар.
ORM не зло, это просто классическая «дырявая абстракция».
Если ей пользуешься, то надо понимать что будет происходить на самом деле. Когда человек в курсе того, что описано в той же спецификации JPA (JSR-000317), то он не будет делать глупостей — SQL генерирутеся для запросов вполне предсказуемо.
Для проектов, где производительность не является приоритетынм не функциональным требованием ORM окажет существенную помощь.
В сертификации Oracle на Java Architect явно проверяется знание того, что, если у вас среди не функциональных требований стоит производительность — вы не станете использовать ORM. И это правильно.
Мы же наблюдаем любовь пихать тот же Hbernate к месту и не к месту. А мне потом уже какой по счету проект, где меня привлекают к решению его технических проблем, приходится с матами заниматься вытягиванием производительности на приемлимый уровень.
Кстати, если говорить об ORM, то EclipseLink по качеству на голову привосходит Hibernate (с которым просто невозможно работать, не зная кучу особенностей его поведения, чтобы не наступать на грабли постоянно).
Если ей пользуешься, то надо понимать что будет происходить на самом деле. Когда человек в курсе того, что описано в той же спецификации JPA (JSR-000317), то он не будет делать глупостей — SQL генерирутеся для запросов вполне предсказуемо.
Для проектов, где производительность не является приоритетынм не функциональным требованием ORM окажет существенную помощь.
В сертификации Oracle на Java Architect явно проверяется знание того, что, если у вас среди не функциональных требований стоит производительность — вы не станете использовать ORM. И это правильно.
Мы же наблюдаем любовь пихать тот же Hbernate к месту и не к месту. А мне потом уже какой по счету проект, где меня привлекают к решению его технических проблем, приходится с матами заниматься вытягиванием производительности на приемлимый уровень.
Кстати, если говорить об ORM, то EclipseLink по качеству на голову привосходит Hibernate (с которым просто невозможно работать, не зная кучу особенностей его поведения, чтобы не наступать на грабли постоянно).
А вот объясните:
Будет считать ORM уровнем абстракции над SQL-запросами.
Допустим, пользоваться ORM должен специалист, понимающий во что преобразуется тот или иной ORM-запрос.
В таком случае, непонятно чем поможет ORM такому специалисту — ведь он все равно в голове будет делать эти преобразования.
Мы можем сказать, что ORM будет понятнее остальным в крупном проекте, но в таком проекте явно удобнее будет свой DSL.
К тому же современные IDE позволяют сворачивать SQL-запрос и давать название свернутому блоку.
Получается, что ORM нужен исключительно для быстрого создания небольших проектов без особой производительности джуниорами?
Будет считать ORM уровнем абстракции над SQL-запросами.
Допустим, пользоваться ORM должен специалист, понимающий во что преобразуется тот или иной ORM-запрос.
В таком случае, непонятно чем поможет ORM такому специалисту — ведь он все равно в голове будет делать эти преобразования.
Мы можем сказать, что ORM будет понятнее остальным в крупном проекте, но в таком проекте явно удобнее будет свой DSL.
К тому же современные IDE позволяют сворачивать SQL-запрос и давать название свернутому блоку.
Получается, что ORM нужен исключительно для быстрого создания небольших проектов без особой производительности джуниорами?
В том-то и дело, что создание такой абстракции целесообразно только в крупных проектах. Кроме того, на мой взгляд, чтобы реально понимать, какой код генерирует ORM, надо знать базы данных лучше, чем чтобы написать запрос самому.
Получается, что грамотно пользоваться технологией может только эксперт в СУБД, которому она, по факту, не нужна — он сам необходимую абстракцию сконструирует. А люди, которым она необходима, ее не понимают, следовательно пишут код неэффективно.
Это — пример не «дырявой», а просто неудачной абстракции, которая закрывая основу, не упрощает жизнь, а усложняет.
Получается, что грамотно пользоваться технологией может только эксперт в СУБД, которому она, по факту, не нужна — он сам необходимую абстракцию сконструирует. А люди, которым она необходима, ее не понимают, следовательно пишут код неэффективно.
Это — пример не «дырявой», а просто неудачной абстракции, которая закрывая основу, не упрощает жизнь, а усложняет.
Я предлагаю относиться к ORM следующим образом:
1) Не рассматривать ORM как абрстракцию изолирующую вас от работы с SQL. Фаулер правильно говорит о 80%. С 20% процентами все равно придется иметь дело.
2) Просмотреть JSR-000317 (написан сухим формальным языком который может быть не так легко читать) или reference manual Hibernate (читается проще), чтобы понять что же вообще могут описывать мэппинги.
Наследование по стандарту JPA может описываться ровно 3 видами связей между таблицами в БД: 2 обязательный к реализации каждым ORM, реализующим JPA стандарт, и 1 опционален (все другие способы на усмотрение авторов фреймворка).
После этого вы поймете что любой ORM будет генерить абсолютно предсказуемый код, так как вариантов там раз два и обчелся. Кстати, Criteria API как и Query language по семантики копируют SQL, так что как ни крутись, а от SQL-ного стиля запросов не избавиться (думаю, это даже хорошо).
Преимущества ORM, которые я считаю полезными (на примере EclipseLink):
1) JPA, начиная с версии 2.0 и появлением Criteria API (в дополнение к query language) и метамодели, позволяющей обращаться к именам колонок (и т.п.) как к переменным класса мета-модели (соответствующим Entity-бину), позволяет проводить рефакторинг средствами IDE (переименовывание), практически не опасаясь, что не будут переименованы имена колонок таблицы в запросах, которые были вбиты в виде строк.
2) Entity бин может быть поднят из БД и, через JAXB, сериализован в XML и JSON (причем в обе стороны, если мне требуется возвращать эти данные через web-сервисы).
3) Spring Data JPA позволяет автоматически создавать DAO с CRUD операциями.
4) Из коробки есть работа с кэшем и не требуется прикручивать свой слой кэшировани.
Есть ряд других и для кого-то они могут быть более значимыми а перечисленные выше — менее. Я, в основном, ориентируюсь на перечисленные выше.
Повторюсь: если среди не функциональных требований нет жестких требований к производительности, то думаем — владеем ли мы ORM в той степени, чтобы не получить больше вреда чем пользы. Также думаем, а не будет ли нам удобнее использовать тот же MyBatis или jOOQ.
ORM никогда не избавит от необходимости связываться с SQL, он облегчит решение ряда рутинных задач при работе с БД, но только если вы умеете им пользоваться :)
А если не думать, а как в анекдоте: «Чего тут думать? Прыгать надо!» — то и результат соответствующий.
1) Не рассматривать ORM как абрстракцию изолирующую вас от работы с SQL. Фаулер правильно говорит о 80%. С 20% процентами все равно придется иметь дело.
2) Просмотреть JSR-000317 (написан сухим формальным языком который может быть не так легко читать) или reference manual Hibernate (читается проще), чтобы понять что же вообще могут описывать мэппинги.
Наследование по стандарту JPA может описываться ровно 3 видами связей между таблицами в БД: 2 обязательный к реализации каждым ORM, реализующим JPA стандарт, и 1 опционален (все другие способы на усмотрение авторов фреймворка).
После этого вы поймете что любой ORM будет генерить абсолютно предсказуемый код, так как вариантов там раз два и обчелся. Кстати, Criteria API как и Query language по семантики копируют SQL, так что как ни крутись, а от SQL-ного стиля запросов не избавиться (думаю, это даже хорошо).
Преимущества ORM, которые я считаю полезными (на примере EclipseLink):
1) JPA, начиная с версии 2.0 и появлением Criteria API (в дополнение к query language) и метамодели, позволяющей обращаться к именам колонок (и т.п.) как к переменным класса мета-модели (соответствующим Entity-бину), позволяет проводить рефакторинг средствами IDE (переименовывание), практически не опасаясь, что не будут переименованы имена колонок таблицы в запросах, которые были вбиты в виде строк.
2) Entity бин может быть поднят из БД и, через JAXB, сериализован в XML и JSON (причем в обе стороны, если мне требуется возвращать эти данные через web-сервисы).
3) Spring Data JPA позволяет автоматически создавать DAO с CRUD операциями.
4) Из коробки есть работа с кэшем и не требуется прикручивать свой слой кэшировани.
Есть ряд других и для кого-то они могут быть более значимыми а перечисленные выше — менее. Я, в основном, ориентируюсь на перечисленные выше.
Повторюсь: если среди не функциональных требований нет жестких требований к производительности, то думаем — владеем ли мы ORM в той степени, чтобы не получить больше вреда чем пользы. Также думаем, а не будет ли нам удобнее использовать тот же MyBatis или jOOQ.
ORM никогда не избавит от необходимости связываться с SQL, он облегчит решение ряда рутинных задач при работе с БД, но только если вы умеете им пользоваться :)
А если не думать, а как в анекдоте: «Чего тут думать? Прыгать надо!» — то и результат соответствующий.
Самое поразительное, что когда я начал спрашивать старших товарищей — почему так делается, они говорили, что было с самого начала принято решение использовать Hibernate, а потом оптимизировать критичные области! То есть затраты времени на переделку тормозных мест изначально закладывались в бюджет. Зачем использовать технологию, если заранее планируется, что она не годится для решения поставленной задачи — загадка.
Очевидно, написать 100% кода на ORM, а потом 20% переписать — дешевле чем сразу написать 100% нативным SQL.
Вы просто не умеете его готовить.
Во-первых, ORM не ограничивается JPA
Во-вторых, при должной сноровке, на Hibernate можно создать такой маппинг, который сгенерирует ровно те же запросы, что вы руками напишите.
В-третьих, тот же Hibernate позволяет впиливать нативный SQL для различных операций над объектами.
В-четвертых, есть myBatis, который на нативных запросах и базируется, и он тоже ORM.
В-пятых, оптимизация понадобится, от силы в 5% запросов.
Мне очень сложно придумать ситуацию, в которой от ORM будет больше вреда чем пользы.
Во-первых, ORM не ограничивается JPA
Во-вторых, при должной сноровке, на Hibernate можно создать такой маппинг, который сгенерирует ровно те же запросы, что вы руками напишите.
В-третьих, тот же Hibernate позволяет впиливать нативный SQL для различных операций над объектами.
В-четвертых, есть myBatis, который на нативных запросах и базируется, и он тоже ORM.
В-пятых, оптимизация понадобится, от силы в 5% запросов.
Мне очень сложно придумать ситуацию, в которой от ORM будет больше вреда чем пользы.
Это все от того что дилетантам дали инструмент, которым они не умеют пользоваться. Любой нормальный ORM должен уметь генерировать либо позволять делать в ручную маппинг по базе. Сначала всегда должна быть спроектирована база, а уже потом туда наложен ORM. Если ORM позволяет генерить таблицы только из себя, бегите от этого ORM.
Видимо вы родились сразу недилетантом. Призывать кого-то уволить — это слишком.
Раз уж на личности…
А я ни на что и не претендую. Когда я понял, что Java EE для меня слишком сложна — ушел в Android. Но я точно знал, как можно улучшить тот проект, с которого я ушёл, я даже советовался с «отцами» и они говорили, что мои идеи правильные, но…
И вот из-за этого «но» я в первую очередь и ушёл: «но», говорили они, в проекте есть люди, которые просто не поймут твои решения, они для них слишком сложны (хотя поверьте мне, я предлагал довольно простые вещи — ничего экстраординарного). То есть код писался не «просто». Он писался «тупо».
говоря «уволить» я не имею в виду «оставить без работы». Просто считаю, что каждый должен заниматься тем, что у него получается.
Сформулировал грубо, согласен… Резкость моя — результат импульсивной попытки защитить любимый язык программирования… В том числе и от его жадных создателей… эх.
А я ни на что и не претендую. Когда я понял, что Java EE для меня слишком сложна — ушел в Android. Но я точно знал, как можно улучшить тот проект, с которого я ушёл, я даже советовался с «отцами» и они говорили, что мои идеи правильные, но…
И вот из-за этого «но» я в первую очередь и ушёл: «но», говорили они, в проекте есть люди, которые просто не поймут твои решения, они для них слишком сложны (хотя поверьте мне, я предлагал довольно простые вещи — ничего экстраординарного). То есть код писался не «просто». Он писался «тупо».
говоря «уволить» я не имею в виду «оставить без работы». Просто считаю, что каждый должен заниматься тем, что у него получается.
Сформулировал грубо, согласен… Резкость моя — результат импульсивной попытки защитить любимый язык программирования… В том числе и от его жадных создателей… эх.
Java EE придумали умные люди, все эти прослойки вроде ORM, Hibernate и прочих придуманы не от хорошей жизни. Считается, что зарплата разработчика с налогами за месяц по деньгам как сервер, за два месяца — как за мощный сервер. В таком случае гораздо рентабельнее, чтобы разработчик писал пусть медленный, но правильно работающий код со всеми тормозящими прослойками но так, чтобы потом другой в нем мог бы разобраться и поиск багов не затягивался на месяцы. Софтверные проекты пишутся не для того, чтобы кормить разработчиков, а чтобы удовлетворять нуждам бизнеса.
Общего между EE и Android — ЯП Java, ничего другого общего нет. Android пока не царствует на серверах, а API серверной джавы отсутствуют на телефонах. Соответственно и сравнивать подходы нельзя. У серверов нет быстро разряжающихся батарей, а в Android есть только SQLite и никакие ORMы не нужны. Сравнивать не корректно.
Общего между EE и Android — ЯП Java, ничего другого общего нет. Android пока не царствует на серверах, а API серверной джавы отсутствуют на телефонах. Соответственно и сравнивать подходы нельзя. У серверов нет быстро разряжающихся батарей, а в Android есть только SQLite и никакие ORMы не нужны. Сравнивать не корректно.
Согласен с вами полностью в той части, которая касается программистов и их зарплаты. Разумеется, там, где можно заменить человека железом, лучше это сделать. Но самые чудовищные, непредсказуемые расходы возникают, когда в большом проекте ломают архитектуру и начинаются непонятные странные ошибки и проблемы, которые подпирают костылями, периодически слетающими и неработающими… Этосамое страшное. Из-за этого иногда приходится весь проект переделывать заново. Поэтому «дырявые абстракции» не годятся. Можно потом сильно пожалеть…
Что касается того, что ORM придумали «умные люди», вот, прочтите статью Мартина Фаулера, в которой он объясняет, почему многим не очень нравится ORM, как с этим бороться и как жить. И хотя он в целом рекомендует пользоваться имеющимися решениями, вместо того, чтобы изобретать свои велосипеды, оговорок и реверансов в разные стороны в тексте тьма тьмущая. Особенно меня забавляет фраза:
Иными словами, «дьявол гнездится в деталях». По моему мнению, «somebody who really understands how a relational database works» может написать уровень абстракций модели даже для крупного проекта и решить задачу запросов конкретно — для данного набора сущностей, вместо того, чтобы впихивать в проект универсальный-на-все-случаи-жизни-решатель, который, как известно, решает все задачи одинаково плохо.
Кстати, я тут не говорю о том, что не советовал делать Фаулер — «создавать свою ORM». Я говорю про то, что надо просто не доводить обобщение задачи до уровня «сохранение какой угодно сущности с какими угодно односторонними или двусторонними связями». Потому что именно это глобальное обобщение и выбрасывает главную мощь баз данных — их производительность. И даже если предположить, что разработчики самих ORM — гении и ангелы, и там нет ошибок внутри, сложность конкретного решения под данный проект всегда ниже. Но нет предела человеческой лени…
И, кстати, Андроид действительно не похож на Java EE, но ORM там стараются не использовать не из-за того, что в ней нет надобности (как раз для небольших проектов ее рекомендуют), а из-за того, что пользователь обычно звереет, когда ему говорят, что этот «Калькулятор семейных финансов 2.0» не будет работать на вашем допотопном одноядерном телефоне со всего одним гигабайтом памяти — идите, купите себе новый за полштуки баксов. Лишние тормоза, на которые при известном уровне аппаратного обеспечения можно забить, неприемлимы в мобильной разработке.
Что касается того, что ORM придумали «умные люди», вот, прочтите статью Мартина Фаулера, в которой он объясняет, почему многим не очень нравится ORM, как с этим бороться и как жить. И хотя он в целом рекомендует пользоваться имеющимися решениями, вместо того, чтобы изобретать свои велосипеды, оговорок и реверансов в разные стороны в тексте тьма тьмущая. Особенно меня забавляет фраза:
Essentially the ORM can handle about 80-90% of the mapping problems, but that last chunk always needs careful work by somebody who really understands how a relational database works.
Иными словами, «дьявол гнездится в деталях». По моему мнению, «somebody who really understands how a relational database works» может написать уровень абстракций модели даже для крупного проекта и решить задачу запросов конкретно — для данного набора сущностей, вместо того, чтобы впихивать в проект универсальный-на-все-случаи-жизни-решатель, который, как известно, решает все задачи одинаково плохо.
Кстати, я тут не говорю о том, что не советовал делать Фаулер — «создавать свою ORM». Я говорю про то, что надо просто не доводить обобщение задачи до уровня «сохранение какой угодно сущности с какими угодно односторонними или двусторонними связями». Потому что именно это глобальное обобщение и выбрасывает главную мощь баз данных — их производительность. И даже если предположить, что разработчики самих ORM — гении и ангелы, и там нет ошибок внутри, сложность конкретного решения под данный проект всегда ниже. Но нет предела человеческой лени…
И, кстати, Андроид действительно не похож на Java EE, но ORM там стараются не использовать не из-за того, что в ней нет надобности (как раз для небольших проектов ее рекомендуют), а из-за того, что пользователь обычно звереет, когда ему говорят, что этот «Калькулятор семейных финансов 2.0» не будет работать на вашем допотопном одноядерном телефоне со всего одним гигабайтом памяти — идите, купите себе новый за полштуки баксов. Лишние тормоза, на которые при известном уровне аппаратного обеспечения можно забить, неприемлимы в мобильной разработке.
Виртуальная машина со сборщиком мусора согласно парадигме должна освобождать от обязанности следить за выделением и освобождением памяти. И мыслить на более высоком уровне абстракции, не заморачиваясь на то, как написать эффективный код с точки зрения расходования ресурсов. Это на себя должна на себя брать виртуальная машина и интерпретатор (jit компилятор).
То, что для того, чтобы писать эффективно на обсуждаемом языке программирования, нужно иметь какие то очень глубокие знания платформы (то, что вы называете «не быть дилетантом») — это недостаток платформы в рамках парадигмы виртуальных машин.
А «тяп ляп и напишем» бывает разный. Можно написать эффективный код с точки зрения расходования ресурсов — но совершенно нечитабельный, можно красивый и медленный, можно отличный и в том и в другом и с дурацкой архитектурой приложения. Все это разные знания. Освобождая свой мозг от одних — можно быть лучшим специалистом в других. Гордость тем, что вы разбираетесь в одном из аспектов и называть тех, кто в них не разбирается «дилетантами» может ввести в заблуждение по поводу Вашего профессионального уровня.
То, что для того, чтобы писать эффективно на обсуждаемом языке программирования, нужно иметь какие то очень глубокие знания платформы (то, что вы называете «не быть дилетантом») — это недостаток платформы в рамках парадигмы виртуальных машин.
А «тяп ляп и напишем» бывает разный. Можно написать эффективный код с точки зрения расходования ресурсов — но совершенно нечитабельный, можно красивый и медленный, можно отличный и в том и в другом и с дурацкой архитектурой приложения. Все это разные знания. Освобождая свой мозг от одних — можно быть лучшим специалистом в других. Гордость тем, что вы разбираетесь в одном из аспектов и называть тех, кто в них не разбирается «дилетантами» может ввести в заблуждение по поводу Вашего профессионального уровня.
Виртуальная машина со сборщиком мусора согласно парадигме должна освобождать от обязанности следить за выделением и освобождением памяти.
Она эту задачу и решает. До тех пор, покуда разработчик не напишет в коде что-нибудь типа:
public class LogCollector {
private List<String> logs = new ArrayList<String>();
public void addLog(String log) {
logs.add(log);
}
public String getLog(int index) {
return logs.get(index);
}
private static LogCollector instance = new LogCollector();
public static LogCollector getInstance() {
return instance;
}
}
Мы же с вами со сборщиком мусора имеем дело, так ведь? Стало быть утечка памяти вообще никогда-никогда невозможна?
Или, например, разработчик ставит системными средствами в обход всяких джентльменских соглашений приоритет какому-нибудь потоку повыше, чтобы быстрее отработал — вот вам и тормоза. Средний программист C или C++ никогда такой глупости не совершит — он знает, как это всё работает. А Java очень проста в освоении — поэтому в ней случаются такие вещи. Это как та девушка, которая «сама виновата, что ее все насилуют — слишком привлекательная».
нужно иметь какие то очень глубокие знания платформы (то, что вы называете «не быть дилетантом»)
Давайте, прежде всего, вы мне процитируете, где я такое определение дилетанта давал (вроде, не было такого). И вы меня совершенно неверно поняли.
Я писал не про глубокие знания того, что такое Java (хотя их считаю несомненным плюсом). Я встречал нескольких людей, приходивших в Java уже в зрелом возрасте — они не знали ничего о новом языке, но не делали ошибок, типа приведенной мной. Еще раз: проблема Java в том, что за то время, пока ее учит новичок и при том количестве усилий, которое он вынужден для этого приложить, он не успевает понять, что такое программирование в целом. Я же не про какую-то тонкую настройку VM говорю. Я говорю про понимание базовых вещей — как организована память и системные API (хотя бы на уровне того, что есть выделение памяти и почему «всемогущий» GC не всегда вас спасёт). Я лично имел дело с людьми, которые при наличии у них перед глазами программы, жрущей оперативку, впихивали в какой-то ответственный код
System.gc() и искренне удивлялись, почему это не помогает.Я собственноручно проверял на математических задачах производительность HotSpot (сравнивал ее с нативной, выполняя решение систем уравнений методом Гаусса). Программы на Java и C были эквивалентны строка в строку. Разница в производительности составляла считанные проценты. Этот тест, разумеется, не исчерпывающий, но он весьма показателен (тот же тест для кода на python, например, давал приблизительно 1/10 от нативной производительности). Это я к тому, что «тормозная Java» — это абсолютный миф. Нормально написанный код будет работать быстро.
А «тяп ляп и напишем» бывает разный. Можно написать эффективный код с точки зрения расходования ресурсов — но совершенно нечитабельный, можно красивый и медленный, можно отличный и в том и в другом и с дурацкой архитектурой приложения.
И опять мы с вами не сошлись в понятиях. Для меня «тяп-ляп» означает «сделать, не подумав». Все перечисленные вами варианты подразумевают, что человек к чему-то стремился, просто потеряв балланс. И это уже хорошо само по себе. Но, увы, случается плохочитабельный неэффективный код без всяких намёков на проектирование архитектуры и глючный к тому же. А потом его из-за нехватки времени просто обкладывают костылями и — вуаля! — проект готов.
Такая дрянь, будь она написана на C++, падала бы регулярно с «детскими» ошибками доступа к памяти, давала бы чудовищные утечки и, в результате, не вышла бы в production. А Java всё прощает — она добрая.
Гордость тем, что вы разбираетесь в одном из аспектов и называть тех, кто в них не разбирается «дилетантами» может ввести в заблуждение по поводу Вашего профессионального уровня.
Единственное, к чему я призываю — это быть специалистом в той области, с которой имеешь дело. Если у водителя виноват автомобиль — он плохой водитель. Да, он может тысячу раз бить себя в грудь кулаком и говорить, что он — не автомеханик и эта поломка — не его задача, но если он регулярно не довозит людей до цели — он дилетант. А прощать ему это, или нет — решат клиенты.
Если человек выбрал себе профессию и не пытается разобраться в тех инструментах, с которыми он каждый день работает, то как вы назовёте этого человека?
А если кто-то указывает мне на сделанную мной в рамках рабочего процесса глупость и говорит, что я неправ — я глотаю это и учусь. И моё отношение к окружающим никак не связано с моим профессиональным уровнем.
До тех пор, покуда разработчик не напишет в коде что-нибудь типа:
Долго и вдумчиво смотрел в код, и не увидел утечек. С точки здравого смысла, так делать не стоит, поскольку ArrayList может занимать значительную память, но если перейти к конкретике, то тут, возможно, стоило бы переопределить конструктор, сделав его приватным, и на этом вроде бы все. Я прав, или в моих знаниях есть пробел?
Я привел «от балды» пример кода, который просто запоминает неограниченно много данных в памяти, никак их не кешируя/не удаляя. Я встречал подобный подход в программах. Иногда, даже если утечки составляют считанные килобайты в час, при запуске такого кода в рамках серверного приложения, через неделю работы вы это почувствуете. А если таких мест много, результат предсказуем.
Цель была в том, чтобы проиллюстрировать, что от алгоритмической/архитектурной безалаберности никакой GC не спасёт.
Цель была в том, чтобы проиллюстрировать, что от алгоритмической/архитектурной безалаберности никакой GC не спасёт.
Тут целых три потенциальных проблемы.
- Заполнение списка без очистки может привести к утечкам памяти. Пока не стрельнет сложно обнаружить, где именно могут быть утечки.
- Глобальное изменяемое состояние трудно отслеживать. Как правило, точек доступа к глобальным данным много или очень много, и чтобы отследить все сценарии и ничего не забыть, нужно много усилий. Иногда даже слишком много для человека.
- Да, и глобальные Singleton'ы трудно тестировать, т.к. его состояние необходимо приводить к исходному для каждого теста, а это не всегда просто (если вообще возможно).
Знаете, уровень необходимых знаний зависит от точки приложения.
И если это простенький сервер с низкой нагрузкой, то даже откровенные тормоза и N + 1 запрос могут быть приемлемыми для заказчика. Так что оценивать уровень разработчика по количеству и работе его проектов в боевых условиях не есть адекватно, хотя может быть показательно. Это как тестирование — оно способно выявить некоторые ошибки, но не гарантировать, что их нет.
А насчет уровня знаний и умений разработчика…
Есть очень много аспектов. Есть знания языка: синтаксис, семантика, порядок вызовов, приоритеты и т.д… Есть знания платформы: устройство памяти, синхронизация потоков, JIT и т.д.
Есть знания framework'ов: открытая документация, знание архитектуры, умение применять в типичных и нетипичных местах, знать подводные камни и известные грабли.
Есть еще знания принципов ООП, функционального программирования, умения строить дизайн, разруливать зависимости, видеть потенциальные проблемы, возможные ошибки новичков, уметь написать так, чтобы ошибки становились очевидными, падали сразу и т.д.
Также еще есть знания среды разработки и исполнения: что где настроить, как подружиться с IDE, как эффективно писать код, всякие там генераторы и т.д.
А теперь, внимание, вопрос: как при таком множестве факторов проверить, является ли кандидат адекватным разработчиков для вашего проекта, или не является?
И второй, встречный вопрос: в какую сторону развиваться человеку, чтобы стать адекватным разработчиком вне зависимости от проекта, в который он попадет?
Вот на пересечении этих интересов и есть истина.
И из личного опыта: чем больше кандидат разбирается в деталях языка и платформы, тем более хороший и качественный код он пишет. Чем шире кругозор — тем проще ему будет вникнуть в незнакомые аспекты, и тем меньше ошибок он допустит. И, за исключением особых случаев, широта лучше глубины. IMHO.
:-)
И если это простенький сервер с низкой нагрузкой, то даже откровенные тормоза и N + 1 запрос могут быть приемлемыми для заказчика. Так что оценивать уровень разработчика по количеству и работе его проектов в боевых условиях не есть адекватно, хотя может быть показательно. Это как тестирование — оно способно выявить некоторые ошибки, но не гарантировать, что их нет.
А насчет уровня знаний и умений разработчика…
Есть очень много аспектов. Есть знания языка: синтаксис, семантика, порядок вызовов, приоритеты и т.д… Есть знания платформы: устройство памяти, синхронизация потоков, JIT и т.д.
Есть знания framework'ов: открытая документация, знание архитектуры, умение применять в типичных и нетипичных местах, знать подводные камни и известные грабли.
Есть еще знания принципов ООП, функционального программирования, умения строить дизайн, разруливать зависимости, видеть потенциальные проблемы, возможные ошибки новичков, уметь написать так, чтобы ошибки становились очевидными, падали сразу и т.д.
Также еще есть знания среды разработки и исполнения: что где настроить, как подружиться с IDE, как эффективно писать код, всякие там генераторы и т.д.
А теперь, внимание, вопрос: как при таком множестве факторов проверить, является ли кандидат адекватным разработчиков для вашего проекта, или не является?
И второй, встречный вопрос: в какую сторону развиваться человеку, чтобы стать адекватным разработчиком вне зависимости от проекта, в который он попадет?
Вот на пересечении этих интересов и есть истина.
И из личного опыта: чем больше кандидат разбирается в деталях языка и платформы, тем более хороший и качественный код он пишет. Чем шире кругозор — тем проще ему будет вникнуть в незнакомые аспекты, и тем меньше ошибок он допустит. И, за исключением особых случаев, широта лучше глубины. IMHO.
:-)
Извиняюсь, перепутал с Flash, а так да, жаль что начинаются такие войны.
Но Java или разработчики (Jenkins, Atlassian, Tomcat) — кто-то из них точно виноват в утечке памяти.
Но Java или разработчики (Jenkins, Atlassian, Tomcat) — кто-то из них точно виноват в утечке памяти.
Это вы мощно перепутали, я бы так не смог :)
И Jenkins, и Jira, и TomCat, и, например, SourceTree, а также SmartGit и Eclipse — всё это я активно использую в работе. Всё написано на Java хотя бы отчасти. Никаких особых утечек не замечал — разве что TomCat периодически не может нормально отключить крупный проект от обслуживания по каким-то левым причинам, связанным со Spring, но он честно в этом признается. Здесь, думаю, вина моя — не умею со Spring работать…
Поймите одну вещь: Java — очень простая и отлично отлаженная технология. Виртуальная машина вылизывается колоссальным числом разработчиков уже почти двадцать лет! Принципиальных проблем там быть просто не может — их бы уже лет десять назад нашли. Там могут быть мелкие ошибки, которые относятся к новым функциям и, скорее всего, к библиотеке классов. Сама ВМ и сборщик — скорее всего стерильно чисты. И когда я слышу про то, что в Java течет память, я без доказательств не верю. Еще в падение производительности за счет вызовов того же GC я поверить могу, но вот что он что-то не собирает… Там в основе математика сравнительно несложная, весь язык проверен и прощупан. Это же не C++ с его заморочками.
И Jenkins, и Jira, и TomCat, и, например, SourceTree, а также SmartGit и Eclipse — всё это я активно использую в работе. Всё написано на Java хотя бы отчасти. Никаких особых утечек не замечал — разве что TomCat периодически не может нормально отключить крупный проект от обслуживания по каким-то левым причинам, связанным со Spring, но он честно в этом признается. Здесь, думаю, вина моя — не умею со Spring работать…
Поймите одну вещь: Java — очень простая и отлично отлаженная технология. Виртуальная машина вылизывается колоссальным числом разработчиков уже почти двадцать лет! Принципиальных проблем там быть просто не может — их бы уже лет десять назад нашли. Там могут быть мелкие ошибки, которые относятся к новым функциям и, скорее всего, к библиотеке классов. Сама ВМ и сборщик — скорее всего стерильно чисты. И когда я слышу про то, что в Java течет память, я без доказательств не верю. Еще в падение производительности за счет вызовов того же GC я поверить могу, но вот что он что-то не собирает… Там в основе математика сравнительно несложная, весь язык проверен и прощупан. Это же не C++ с его заморочками.
Очень спать хотелось, но полез коммент писать :(
С языками программирования не знаком, только слышал, поэтому ничего не могу внятного сказать.
Jira при обновлении плагинов, у меня, часто начинает жрать память и проц, в итоге приходится её перезапускать (внутрь никто не лез, всё исходно, периодически обновляю систему), Stash иногда падает сам по себе, узнаю только от разработчиков, так же поедает все 8 гигов памяти и 8 потоко в процессора.
Есть, конечно, большая вероятность что во всём виноват я, что «слабое железо» и надо более современное, но есть и другая вероятность что во всём виноваты разработчики, но всегда, как думают хомячки и многие другие, виновата исходная система, благодаря чему это всё работает, вот и приходится безосновательно верить что это всё происки разработчиков.
И спрошу Вас через личные сообщения, если не против, по поводу работы jenkins, уж часто ошибки возникают.
С языками программирования не знаком, только слышал, поэтому ничего не могу внятного сказать.
Jira при обновлении плагинов, у меня, часто начинает жрать память и проц, в итоге приходится её перезапускать (внутрь никто не лез, всё исходно, периодически обновляю систему), Stash иногда падает сам по себе, узнаю только от разработчиков, так же поедает все 8 гигов памяти и 8 потоко в процессора.
Есть, конечно, большая вероятность что во всём виноват я, что «слабое железо» и надо более современное, но есть и другая вероятность что во всём виноваты разработчики, но всегда, как думают хомячки и многие другие, виновата исходная система, благодаря чему это всё работает, вот и приходится безосновательно верить что это всё происки разработчиков.
И спрошу Вас через личные сообщения, если не против, по поводу работы jenkins, уж часто ошибки возникают.
У нас тоже так: плагин ставишь, понеслось до 95% процессор жрать, тупить и т.д.
Пока была небольшая нагрузка и мало заявок, было нормально, теперь плагины и прочее обновляю только по вечерам/ночам, когда почти никто не работает, иначе ждут долго, минут по 10, пока рассосется
Что оно там делает в этот момент, непонятно
Еще сильно все зависит от количества памяти: сейчас дадено 10 Гиг, сама по себе почти не падает, но надо бы еще 4-6 выдать, для верности, иногда впритык. Очень они, такие приложения, когда оно внутри себя объекты строит и по индексам ходит, любят память, много памяти. И диски любят, и процессоры тоже :)
Пока была небольшая нагрузка и мало заявок, было нормально, теперь плагины и прочее обновляю только по вечерам/ночам, когда почти никто не работает, иначе ждут долго, минут по 10, пока рассосется
Что оно там делает в этот момент, непонятно
Еще сильно все зависит от количества памяти: сейчас дадено 10 Гиг, сама по себе почти не падает, но надо бы еще 4-6 выдать, для верности, иногда впритык. Очень они, такие приложения, когда оно внутри себя объекты строит и по индексам ходит, любят память, много памяти. И диски любят, и процессоры тоже :)
стимулирования инноваций и уверенности, что разработчики будут вознаграждены за свои достижения».
Ну, и сколько разработчики получили из 1 млрд зеленых?
При чем здесь это?
Оракл имеют в виду, что теперь разработчики не попадут в ситуацию, когда их труд использовали для наживы.
Хотя лично я считаю это высказывание не более чем пафосным оправданием того, что они, грубо говоря, украли у гугл миллиард
Оракл имеют в виду, что теперь разработчики не попадут в ситуацию, когда их труд использовали для наживы.
Хотя лично я считаю это высказывание не более чем пафосным оправданием того, что они, грубо говоря, украли у гугл миллиард
заявление реально глупое. интересно как вообще решение суда согласуется с тем что код не может быть предметом авторского права — уже было вроде по этому поводу судебное решение.
>Оракл имеют в виду, что теперь разработчики не попадут в ситуацию, когда их труд использовали для наживы
То есть Оракл использует труд разработчиков Java для наживы и при этом утверждает, что труд разработчиков не будет использован для наживы. Логично, угу.
То есть Оракл использует труд разработчиков Java для наживы и при этом утверждает, что труд разработчиков не будет использован для наживы. Логично, угу.
Я полагаю, они их получат в виде зарплат, они же не с неба берутся.
Интересно, на сколько возрастет цена андроид устройств?
я думаю Oracle для того и купил Sun :)
Интересно какая судьба ожидает проекты, которые занимаются сторонней реализацией API Dalvik: Alien Dalvik, ACL, PAG и т.п.
Почему бы Google не переписать API на Scala? Благо, из java оно легко вызывается.
выиграла не «суд», а «аппеляцию». Разумеется, это дойдёт до Supreme Court. Плюс, есть вероятность, что этот объём цитирования признают fair use и узаконят практику fair use использования хидеров для совместимости.
Миллиардом больше, миллиардом меньше — имхо гуглу без разницы, это не запрет продавать любые телефоны с Андроидам всем на свете без возможности обжалования.
Проблема в том, что может создаться прецедент. «На примерe Google мы показали, что API подвержено авторскому праву. Давайте-ка сюда кто там ещё Java реализовал». И Java, опять же, может быть только началом.
Ну да, тут можно будет сразу зарубить такие проекты, как ReactOS.
Но все же, прочитав заголовок, я ожидал худшего. Я ожидал, что на программу, которую я написал, приобретают авторские права те, кто создал язык программирования.
Но все же, прочитав заголовок, я ожидал худшего. Я ожидал, что на программу, которую я написал, приобретают авторские права те, кто создал язык программирования.
Программу вашу никому трогать и не надо. Просто вам, например, предложат заплатить за javac. Или за jvm. Или скажут, что вы должны им 5% с ваших доходов с этой программы.
Им невыгодно вас губить, поймите. Им надо, чтобы вы жили и развивались… в клетке, периодически принося им «потомство».
Им невыгодно вас губить, поймите. Им надо, чтобы вы жили и развивались… в клетке, периодически принося им «потомство».
А кто его знает. Может они решат, что наследование от IComparable или переопределение hashCode/equals это тоже копирование Java API.
Вот этого я тоже очень боюсь… за Avian, например.
долго думал, чтоб написать такого… но не могу описать того, как я сплюнул просто — как старый дед, который говорит: «Ох, молодеж, коммерсанты хреновы».
Особенно смешно выглядит словосочетание «стимулирование инноваций» в данном контексте. По-моему подобная практика наоборот замедляет инновации и очень печально, что закон стоит на ее стороне.
Интернет тролли комментят патентных:)
Картинка к статье хороша :)
Непонятно почему google использовала язык java в андроиде. Сделали бы свой язык с привычным си-подобным синтаксисом (да хоть клон java с минимальными изменениями и другим названием для начала) и спокойно бы его развивали, как MS развивает C# (который, кстати сказать, развивается гораздо быстрее java). И новые фичи в языке появлялись бы быстрее (это кроме всего прочего и просто интересно), и никакие патентные тролли не докопались бы.
Ну хотя бы потому, что Android изначально разрабатывался как ОС для обычных кнопочных телефонов, где Java была царем и богом, и в самом Google является частью «святой троицы» основных языков — C++, Java, Python. А затем на сцену вышла Apple с iPhone и Google пришлось в срочном порядке допиливать дроида для работы с сенсорными экранами и как можно быстрее релизить, чтобы не оказаться в позиции безнадежного отставания. Разработка же нового языка — это дело очень длительное и дорогое, а любая ошибка в дизайне может привести к миллиону лет мучений с legacy кодом (кхм, JavaScript, кхм).
Пользуясь случаем, прикладываю ссылочки, чтобы проиллюстрировать ваше утверждение про андроид до iphone.
www.theverge.com/2012/4/25/2974939/android-in-early-2007-looked-very-different-than-it-does-today
www.engadget.com/2007/11/12/a-visual-tour-of-androids-ui/
www.theverge.com/2012/4/25/2974939/android-in-early-2007-looked-very-different-than-it-does-today
www.engadget.com/2007/11/12/a-visual-tour-of-androids-ui/
Google рассматривала возможность использовать C# и CLR.
Ну сейчас бы microsoft с них миллиард баксов снял.
Крупным корпорациям нужно иметь собственные языки программирования, или пользоваться «общедоступными». Хорошо конечно при этом, если корпорация делает их «общедоступными» (типа С++… кстати интересен его статус, ведь Страуструп изобрел его будучи сотрудником AT&T Bell Labs… ).
Крупным корпорациям нужно иметь собственные языки программирования, или пользоваться «общедоступными». Хорошо конечно при этом, если корпорация делает их «общедоступными» (типа С++… кстати интересен его статус, ведь Страуструп изобрел его будучи сотрудником AT&T Bell Labs… ).
Microsoft в теории мог бы попробовать снять миллиард, но это осложняется тем, что C# и CLI стандартизованы в ECMA. Почему в Google отказались от этой идеи я не знаю. Вероятно, они уверены, что их позиция по fair use прокатит, а Java всё же популярнее среди разработчиков, чем C#.
Какой бы прекрасный ни был язык, он абсолютно бесполезен, если нет программистов, которые бы умели его использовать. Их нужно привлечь с другим языков. С этим расчетом, кстати, Java и разрабатывалась — просто, легко, эдакий C++ для чайников (Java великолепный язык, не принимайте близко к сердцу это высказывание, оно лишь для более простого понимания моей идеи), бери и программируй, почти без подготовки. Так что в свое время он он здорово нашумел, что хорошо прослеживается и по современным рейтингам ЯП. Хотя до конца не ясно было, где эту мощь применить — то ли в кофеварке, то ли в браузере…
А новый язык в наше время это… это как новая мобильная ОС! Никого уже ничем не удивишь… Сборка мусора? Отражение? Функциональная стандартная библиотека? Многопоточность на уровне языка? Это уже не киллер фичи =\ А хрен на хрен менять, как утверждает русская пословица, только время терять.
Поэтому я лично бы с Вами поспорил насчет «Крупным корпорациям нужно иметь собственные языки программирования». Не все так просто.
А новый язык в наше время это… это как новая мобильная ОС! Никого уже ничем не удивишь… Сборка мусора? Отражение? Функциональная стандартная библиотека? Многопоточность на уровне языка? Это уже не киллер фичи =\ А хрен на хрен менять, как утверждает русская пословица, только время терять.
Поэтому я лично бы с Вами поспорил насчет «Крупным корпорациям нужно иметь собственные языки программирования». Не все так просто.
Давайте помечтаем…
Допустим, появился бы язык, схожий с Java и C#, построенный, например, на LLVM и развиваемый сообществом. Этакий «новый свободный C++». Неужели мир бы не выиграл от такого решения? Мне кажется, что ситуация в индустрии деградирует из-за того, что вместо того, чтобы развивать что-то общее, как корпорации это делали в 70-90е годы прошлого века, теперь все грызутся по мелочам. У меня только одно объяснение — всем слишком легко живется. Рынок насыщен и пересыщен, все программы уже написаны — остается рвать последние куски. Победит тот, кто сможет заставить всех пользователей мира использовать его язык, ОС и браузер. Или…
… или они, всё же, увидят, что зашли в тупик, договорятся, и мы наконец увидем новый замечательный язык программирования, в который вложат свой мозг Microsoft, Google, Oracle, IBM и Apple. И на котором можно будет писать middleware без опасения, что завтра кто-нибудь запретит тебе его запускать или сделать для него очередной компилятор…
Допустим, появился бы язык, схожий с Java и C#, построенный, например, на LLVM и развиваемый сообществом. Этакий «новый свободный C++». Неужели мир бы не выиграл от такого решения? Мне кажется, что ситуация в индустрии деградирует из-за того, что вместо того, чтобы развивать что-то общее, как корпорации это делали в 70-90е годы прошлого века, теперь все грызутся по мелочам. У меня только одно объяснение — всем слишком легко живется. Рынок насыщен и пересыщен, все программы уже написаны — остается рвать последние куски. Победит тот, кто сможет заставить всех пользователей мира использовать его язык, ОС и браузер. Или…
… или они, всё же, увидят, что зашли в тупик, договорятся, и мы наконец увидем новый замечательный язык программирования, в который вложат свой мозг Microsoft, Google, Oracle, IBM и Apple. И на котором можно будет писать middleware без опасения, что завтра кто-нибудь запретит тебе его запускать или сделать для него очередной компилятор…
вместо того, чтобы развивать что-то общее, как корпорации это делали в 70-90е годы прошлого века
Нужно начать с того, что мы с Вами до сих пор пользуемся x86. Наследием того старого (но хорошего) процессора! Поразительно, но уже тридцать лет все самые новые и крутые процессоры сохраняют совместимость с ним, а иначе что? Intel попробовала, мы увидели Itanium. Как его не славили теоретики, до практики не дошло ничего. Нужна прямо-таки революция, чтобы x86 забросили. И с языками примерно то же самое.
Кстати, отличный свободный язык — D. Декларируется, что в нем исправлены все недостатки C++. Но где она, критическая масса пользователей? А хрен ее знает, даже использование его фейсбуком не помогло, как ни странно…
Подождите, может еще накопится. Надо, чтобы его в течение лет пяти-шести использовали крупные разработчики. Чего этому языку не хватает — так это инфраструктуры. Где шикарная кросс-платформенная IDE? Вспомните, например, Delphi (не кроссплатформенная, если не считать Kylix, но шикарная). Компилятор сам по себе никому не нужен кроме гиков-полиглотов.
А насчет «забросили» — я не говорю «выкиньте все старые языки и создайте вместо них новый». Я о том, чтобы было некое средство, позволяющее программировать удобно, легко, без оглядки и опасений на лицензионные проблемы…
Математики же, например, используя в доказательстве какую-нибудь из теорем Коши, не думают, что их доказательство станет незаконным, если так решат потомки Коши, так ведь?
На мой взгляд, должна поменяться мораль сообщества. Например, сейчас уже стало «дурным вкусом» делать программы общего назначения (например, игры) под какую-нибудь одну платформу (если только ты не разработчик этой самой платформы). Стараются портировать везде, где только можно. Так вот, по-моему, следующим шагом в развитии «общественного сознания» должно быть признание, что проприетарные технологии в языках программирования — тоже «дурной вкус». И подвижки есть… Но пока весь мейнстрим занят проприетарными технологиями, улучшений не будет.
А насчет «забросили» — я не говорю «выкиньте все старые языки и создайте вместо них новый». Я о том, чтобы было некое средство, позволяющее программировать удобно, легко, без оглядки и опасений на лицензионные проблемы…
Математики же, например, используя в доказательстве какую-нибудь из теорем Коши, не думают, что их доказательство станет незаконным, если так решат потомки Коши, так ведь?
На мой взгляд, должна поменяться мораль сообщества. Например, сейчас уже стало «дурным вкусом» делать программы общего назначения (например, игры) под какую-нибудь одну платформу (если только ты не разработчик этой самой платформы). Стараются портировать везде, где только можно. Так вот, по-моему, следующим шагом в развитии «общественного сознания» должно быть признание, что проприетарные технологии в языках программирования — тоже «дурной вкус». И подвижки есть… Но пока весь мейнстрим занят проприетарными технологиями, улучшений не будет.
старого (но хорошего) процессора
— В нем нет абсолютно ничего хорошего. Перегруженная система комманд, неудобная как для декодера, так и для компилятора; куча никому давно не нужных рудиментов; костыль на костыле. Восемьдесят шестой давно себя изжил, он не планировался как основа системы совместимых машин. Его должен был заменить четыреста тридцать шестой, но инжинеры перемудрили. Единственный его плюс — огромное количество программ под него, но с точки зрения архитектуры это — тупик.
— В нем нет абсолютно ничего хорошего. Перегруженная система комманд, неудобная как для декодера, так и для компилятора; куча никому давно не нужных рудиментов; костыль на костыле. Восемьдесят шестой давно себя изжил, он не планировался как основа системы совместимых машин. Его должен был заменить четыреста тридцать шестой, но инжинеры перемудрили. Единственный его плюс — огромное количество программ под него, но с точки зрения архитектуры это — тупик.
Так вышло бы намного дороже — как разработка самого языка, так и привлечение программистов на новый, незнакомый язык. Google сэкономил.
А Что это означает для обычных пользователей и для индустрии?
То есть своя jvm — это преступление, нарушающее авторское право oracle? То если ты делаешь железку, и софт к ней делаешь на жаве — это нарушени прав оракла? Или как? А как же то, что жава свободна?
Или речь идет о том, что гугл зявила, что этот язык — не жава, а их разработка?
То есть своя jvm — это преступление, нарушающее авторское право oracle? То если ты делаешь железку, и софт к ней делаешь на жаве — это нарушени прав оракла? Или как? А как же то, что жава свободна?
Или речь идет о том, что гугл зявила, что этот язык — не жава, а их разработка?
А ведь Столлман предупреждал.
We do have free implementations of Java, such as the GNU Compiler for Java (GCJ) and GNU Classpath, but they don't support all the features yet. We are still catching up.
Если я правильно понимаю, даже Столлман недооценивал масштаб катастрофы. Ведь если суд будет выигран, то сами попытки сторонней имплементации Java API станет незаконным без договорённости с Oracle. То есть возможность создать «свой язык, подозрительно похожий на Java» с тем, чтобы перенести под него код своих проектов «в случае чего» (как это, кстати, уже пытался сделать Apache). Выживет только OpenJDK, которая GPL, то есть включить ее в коммерческое приложение нельзя.
А еще признание эксклюзивного права создателя API на его имплементацию сделает шатким юридическое положение таких замечательных проектов, как MinGW, например. Так что для сообщества программистов, ценящих открытые лицензии, отличные от GPL, новость кошмарная.
Да даже сам Linux может попасть под раздачу, ведь он реализует Unix APIs, которые теперь тоже будут защищены копирайтом.
Лицензия OpenJDK — это не чистая GPL, а GPL + linking exception. То есть его МОЖНО использовать в коммерческих проектах.
Поправьте, если не прав.
Поправьте, если не прав.
Я в юриспруденции, увы, не силён.
Linking exception, насколько я понимаю, касается только Classpath. То есть особенность языка Java в том, что так как без Classpath ничего не будет работать, а загрузку его одновременно с основной программой разумно считать линковкой, то оригинальная GPL позволяла бы зопускать под OpenJDK только GPL-совместимый код. Это зверское ограничение не дало бы никакой возможности использовать проприетарный (или хотя бы Apache) Java-код в linux, например. То есть когда вы запускаете Apache Tomcat в Debian с OpenJDK — вы как раз пользуетесь этим «linking exception».
Но распространять OpenJDK вместе со сторонними не-GPL проектами, насколько я понимаю, нельзя.
Linking exception, насколько я понимаю, касается только Classpath. То есть особенность языка Java в том, что так как без Classpath ничего не будет работать, а загрузку его одновременно с основной программой разумно считать линковкой, то оригинальная GPL позволяла бы зопускать под OpenJDK только GPL-совместимый код. Это зверское ограничение не дало бы никакой возможности использовать проприетарный (или хотя бы Apache) Java-код в linux, например. То есть когда вы запускаете Apache Tomcat в Debian с OpenJDK — вы как раз пользуетесь этим «linking exception».
Но распространять OpenJDK вместе со сторонними не-GPL проектами, насколько я понимаю, нельзя.
Но распространять OpenJDK вместе со сторонними не-GPL проектами, насколько я понимаю, нельзя.
Спорный вопрос. Вот, что говорит faq по лицензии:
As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
На сколько я понимаю, если я свою проприетарную программу распространяю в пакете с OpenJDK, но не интегрирую их, а держу отдельно друг от друга, тогда моя проприетарная программа является «independed module», и ограничений на такое распространение нет.
Ненавижу Oracle! :(
Я конечно рискую, но всё же выскажу своё мнение, почему я считаю то, что делают Oracle — правильным, хотя бы частично:
Думаю все, кто крутятся в Java среде знают о существовании библии JVM — Blue Book. В ней максимально подробно описано как должна быть реализована JVM. Без жёстких стандартов и спецификаций Java была бы не Java. Для нас, Java разработчиков, Blue Book гарантирует что код будет исполняться одинаково, это те гарантии, которые делают JVM столь привлекательной.
И тут появляется Google, которые кладут большой и толстый на Blue Book, отказываются от сертификации JVM, но при этом всё ещё говорят, что для их VM пишут на Java. Что мы получаем в итоге? «А этот код работает на Android?». Для сравнения можно вспомнить M$, которые в своё время не стали называть шарп джавой и стали развиваться в своём направлении. И никто не пытается теперь подсунуть Java-компилятору C# код.
Я вижу этот суд как попытку наказать Google именно за это, а выбранные рычаги воздействия — это уже другой разговор. Уверен, если бы Google в своё время реализовали полноценную JVM, претензий к ним не было бы.
Думаю все, кто крутятся в Java среде знают о существовании библии JVM — Blue Book. В ней максимально подробно описано как должна быть реализована JVM. Без жёстких стандартов и спецификаций Java была бы не Java. Для нас, Java разработчиков, Blue Book гарантирует что код будет исполняться одинаково, это те гарантии, которые делают JVM столь привлекательной.
И тут появляется Google, которые кладут большой и толстый на Blue Book, отказываются от сертификации JVM, но при этом всё ещё говорят, что для их VM пишут на Java. Что мы получаем в итоге? «А этот код работает на Android?». Для сравнения можно вспомнить M$, которые в своё время не стали называть шарп джавой и стали развиваться в своём направлении. И никто не пытается теперь подсунуть Java-компилятору C# код.
Я вижу этот суд как попытку наказать Google именно за это, а выбранные рычаги воздействия — это уже другой разговор. Уверен, если бы Google в своё время реализовали полноценную JVM, претензий к ним не было бы.
Для сравнения можно вспомнить M$, которые в своё время не стали называть шарп джавой и стали развиваться в своём направленииАга, а MS JavaVM (Sun v. Microsoft, оно же United States v. Microsoft) вы благополучно забыли? Которую они назвали вполне себе явой, но суд Sun'у проиграли. И претензии там были куда более существенные: они говорили о совместимой версии JVM, но вносили явно несовместимые изменения в API.
Также стоит учитывать, что в рамках Android нужен был профиль существенно серьезней, чем Java ME CDC, но не столь ресурсоёмкий, как Java SE. В первую очередь поэтому Dalvik регистровый, а не стековый, как JVM. Иметь же под боком хорошую референс-платформу (JVM) с нормально описанной семантикой (с точки зрения application developer'а описанной в JLS) — это очень удобно.
JVMS (blue book) описывает всякие implementation-specific вещи типа формата class-файла, набора инструкций байткода. Очевидно, что последний должен отличаться для регистровой и стековой машин, что делает невозможным сертификацию DalvikVM в качестве JVM. Наличие транслятора class -> dex этого не отменяет.
Насколько мне известно, Google никогда и нигде не называли язык, использованный для разработки под Android «Java», а Dalvik — JVM. Наоборот, они делают «хорошую мину при плохой игре» — всячески открещиваются от этого названия, чтобы на них не наезжали. Я сам в таких случаях обычно говорю «язык, подозрительно похожий на Java». Если я неправ, приведите, пожалуйста, пример — мне это интересно…
Подскажите, пожалуста, чем заменить пустые строки и int main(int argc,char** argv) в коде? Можно ли как-нибудь автоматизировать этот процесс?
Oracle как были тупыми и жадными мудаками, так и остались капиталистами на всю голову.
Чеклист:
мудаки — (/)
жадные — (/)
капиталисты — (/)
тупые — wat?
Что oracle сделала такого, чтобы считать её тупой?
мудаки — (/)
жадные — (/)
капиталисты — (/)
тупые — wat?
Что oracle сделала такого, чтобы считать её тупой?
1) Жадные капиталисты, ибо купили Sun и:
— поменяли лицензию Java на гораздо менее свободную;
— обрекли на смерть MySql;
— окончательно добили солярис и её сообщество.
2) Тупые, потому что в 2014 году производят и продают по баснословным ценам софт, который выглядит и работает как привет из 90-х.
3) Мудаки, потому что зажали все опенсорс инициативы Sun и стараются строить хорошую мину при плохой игре. Вы перечитайте высказывание Oracle из поста. Для индустрии полезно, что патентный тролль оракл получит кучу бабла выиграет суд, который возможно обяжет гугл и производителей телефонов платить дань за каждый проданный телефон, по аналогии с майкрософтом? Я так не думаю.
Они просто видят жирный кусок пирога и бесятся, что не могут от него откусить.
Таково моё ИМХО. Спорить далее не буду.
— поменяли лицензию Java на гораздо менее свободную;
— обрекли на смерть MySql;
— окончательно добили солярис и её сообщество.
2) Тупые, потому что в 2014 году производят и продают по баснословным ценам софт, который выглядит и работает как привет из 90-х.
3) Мудаки, потому что зажали все опенсорс инициативы Sun и стараются строить хорошую мину при плохой игре. Вы перечитайте высказывание Oracle из поста. Для индустрии полезно, что патентный тролль оракл получит кучу бабла выиграет суд, который возможно обяжет гугл и производителей телефонов платить дань за каждый проданный телефон, по аналогии с майкрософтом? Я так не думаю.
Они просто видят жирный кусок пирога и бесятся, что не могут от него откусить.
Таково моё ИМХО. Спорить далее не буду.
Выступлю «адвокатом дьявола». Не люблю недооценивать противника. Сразу оговорюсь, что это мои личные домыслы, бред и я никого не хочу обидеть или привознести — просто размышляю вслух.
1) Про солярис ничего не знаю — не пользовался, MySQL «убить» невозможно — просто «родилась» MariaDB. А вот про Java скажу: лицензии бывают 3 типов: free as beer, free as Stallman и proprietary. Разница в том, что суть первых «код написал я, но пользуйтесь забесплатно, основывайте на нем свои проекты и никто никому ничего не должен» (это, как я понимаю, MIT, BSD, Apache), вторая — GPL (вариации LGPL, GPL with linkage exception и т. д...), которая ограничивает права разработчика, всячески мешая ему заработать продажей данного кода по принципу «сам не гам и другому не дам». Третья — договор, согласно которому сам по себе код является собственностью автора, а пользователь ограничен в своих правах.
Так вот насколько я понимаю, лицензия у Java всегда была третьего типа, так? Так что Oracle мало что изменил здесь.
2) Простите, они, по-вашему обанкротились? Люди перестали покупать СУБД Oracle Enterprise? Просто, например, Windows ругают почти все, кто им пользуются, но пользователей бесплатного linux всё равно лишь 10%… И да, это — запрещенный аргумент полемики в духе «сперва добейся». Раз покупают у них, значит они не дураки.
3) Sun была довольно (сравнительно) небольшая корпорация, которая своей добротой выработала главный бесценный ресурс — «прикормила» возле Java колоссальное количество разработчиков. И многие из них даже языков других не знают — потеря Java для них станет чуть ли не потерей работы. Но «капитализировать» этот ресурс они были не в состоянии, так как если бы Google (или кто-то того же масштаба) судились с ними, у них бы денег просто не хватило отбиться. Поэтому они продолжали быть «добрыми» — чем меньше компания, тем больше она зависит от своей репутации и сообщества.
Oracle — гигант. Они настолько прочно стоят на ногах, что репутация для них уже ничего не стоит. Сообщество разработчиков для них — дойная корова. И конечно «взять за вымя» всех разработчиков Java в мире, запретив им даже думать о каких-либо альтернативах Oracle JDK для них — лакомый кусок, который им по зубам, как выясняется. Если они победят у самого Google, никто уже с ними тягаться не станет.
Еще раз: главная ценность для них — не Java API. Главная ценность — это мы с вами, наш опыт, человеко-часы, потраченные сообществом на изучение Java и написания кучи, заметьте, бесплатного и открытого кода. Попробуйте найти библиотеку без Java Binding!
Нет, граждане. Они — не мудаки. Они — молодцы… для себя. А кто они для нас с вами — сами понимаете.
1) Про солярис ничего не знаю — не пользовался, MySQL «убить» невозможно — просто «родилась» MariaDB. А вот про Java скажу: лицензии бывают 3 типов: free as beer, free as Stallman и proprietary. Разница в том, что суть первых «код написал я, но пользуйтесь забесплатно, основывайте на нем свои проекты и никто никому ничего не должен» (это, как я понимаю, MIT, BSD, Apache), вторая — GPL (вариации LGPL, GPL with linkage exception и т. д...), которая ограничивает права разработчика, всячески мешая ему заработать продажей данного кода по принципу «сам не гам и другому не дам». Третья — договор, согласно которому сам по себе код является собственностью автора, а пользователь ограничен в своих правах.
Так вот насколько я понимаю, лицензия у Java всегда была третьего типа, так? Так что Oracle мало что изменил здесь.
2) Простите, они, по-вашему обанкротились? Люди перестали покупать СУБД Oracle Enterprise? Просто, например, Windows ругают почти все, кто им пользуются, но пользователей бесплатного linux всё равно лишь 10%… И да, это — запрещенный аргумент полемики в духе «сперва добейся». Раз покупают у них, значит они не дураки.
3) Sun была довольно (сравнительно) небольшая корпорация, которая своей добротой выработала главный бесценный ресурс — «прикормила» возле Java колоссальное количество разработчиков. И многие из них даже языков других не знают — потеря Java для них станет чуть ли не потерей работы. Но «капитализировать» этот ресурс они были не в состоянии, так как если бы Google (или кто-то того же масштаба) судились с ними, у них бы денег просто не хватило отбиться. Поэтому они продолжали быть «добрыми» — чем меньше компания, тем больше она зависит от своей репутации и сообщества.
Oracle — гигант. Они настолько прочно стоят на ногах, что репутация для них уже ничего не стоит. Сообщество разработчиков для них — дойная корова. И конечно «взять за вымя» всех разработчиков Java в мире, запретив им даже думать о каких-либо альтернативах Oracle JDK для них — лакомый кусок, который им по зубам, как выясняется. Если они победят у самого Google, никто уже с ними тягаться не станет.
Еще раз: главная ценность для них — не Java API. Главная ценность — это мы с вами, наш опыт, человеко-часы, потраченные сообществом на изучение Java и написания кучи, заметьте, бесплатного и открытого кода. Попробуйте найти библиотеку без Java Binding!
Нет, граждане. Они — не мудаки. Они — молодцы… для себя. А кто они для нас с вами — сами понимаете.
Интересно, мы увидим теперь срочную разработку (впрочем, завершение ее — уверен, что такие работы «на черный» день где-то в недрах Гугла велись и ведутся) чего-то, что станет основой для следущих версий Андройда?
Я понимаю, как это звучит, стандарты и все такое, но мобильной индустрии не впервой делать ОС, которая, хоть и называется так же, по сути оказывается несовместимой (или, в лучшем случае, не полностью совместимой) с прошлой версией. Да тот же Андройд первых версий вспомните, и как с него на 4.х мигрировали, тот же Андройд 4.0.х и переезд на 4.2-4.3 (ну, там еще и производители не сильно напрягались, но сколько вокруг людей застряли с девайсами, на которых 4.0.4 крутится без надежды на фирменное обновление до 4.2, тогда как сторонние прошивки 4.2 на этим устройства весело привносят), ту же Windows Phone 7.x и (опа!) выход 8.0 — во всех случаях обнаруживалось, что юзерам проще (а производителям быстрее и даже в рекламных целях интереснее) поставить себе обновленную версию того же приложения, собранную под новую ОС и API в ней.
Так вот, если завтра появится новость об Андройде 5.0 с ограниченной совместимостью с прошлыми версиями, и обещаниями к 5.1-5.2 эти соместимости убрать, как в MacOS ушла совместимость с PowerPC-кодом, то будет масса статей, но все смирятся (варианты-то какие?), не особо народ на WP и iOS побежит — и через год-два вопросы от Oracle будут уже риторическими. И тогда Ораклу как-то станет грустно, но время будет упущено.
Я понимаю, как это звучит, стандарты и все такое, но мобильной индустрии не впервой делать ОС, которая, хоть и называется так же, по сути оказывается несовместимой (или, в лучшем случае, не полностью совместимой) с прошлой версией. Да тот же Андройд первых версий вспомните, и как с него на 4.х мигрировали, тот же Андройд 4.0.х и переезд на 4.2-4.3 (ну, там еще и производители не сильно напрягались, но сколько вокруг людей застряли с девайсами, на которых 4.0.4 крутится без надежды на фирменное обновление до 4.2, тогда как сторонние прошивки 4.2 на этим устройства весело привносят), ту же Windows Phone 7.x и (опа!) выход 8.0 — во всех случаях обнаруживалось, что юзерам проще (а производителям быстрее и даже в рекламных целях интереснее) поставить себе обновленную версию того же приложения, собранную под новую ОС и API в ней.
Так вот, если завтра появится новость об Андройде 5.0 с ограниченной совместимостью с прошлыми версиями, и обещаниями к 5.1-5.2 эти соместимости убрать, как в MacOS ушла совместимость с PowerPC-кодом, то будет масса статей, но все смирятся (варианты-то какие?), не особо народ на WP и iOS побежит — и через год-два вопросы от Oracle будут уже риторическими. И тогда Ораклу как-то станет грустно, но время будет упущено.
Я не думаю, что что-то изменится. Google с этим вердиктом апелляционного оказалась в 2014 году в той ситуации, которая ожидалась её адвокатами в 2012. В Маунтин-вью просто получили неожиданную отсрочку на 2 года от того, к чему они готовились раньше.
А сложности перехода от 2.x на 4.x обусловлены совершенно иными причинами. Приложения, написанные под Android 1.5 прекрасно работают на 4.4 без всяких изменений, а вот завести без изменений приложение с WP7 на WP8.1 — другой вопрос.
А сложности перехода от 2.x на 4.x обусловлены совершенно иными причинами. Приложения, написанные под Android 1.5 прекрасно работают на 4.4 без всяких изменений, а вот завести без изменений приложение с WP7 на WP8.1 — другой вопрос.
>>а вот завести без изменений приложение с WP7 на WP8.1 — другой вопрос.
Объясните
Объясните
Некоторые проблемы описаны на MSDN в разделе про CLR.
Похожие проблемы есть и у Android, но система еще ни разу не переживала ничего похожего на смену ядра, хотя существует она дольше Windows Phone.
Похожие проблемы есть и у Android, но система еще ни разу не переживала ничего похожего на смену ядра, хотя существует она дольше Windows Phone.
Опа мне насыпали минусов!
Андройд 1.х я привел как пример. Запуститься старое ПО может и запустится, но, положа руку на сердце — если бы не запустилось, мало бы кто пострадал из широкой публики. WP все же как пример показательнее — и никто не умер, хотя поступил MS тогда вполне по-своему, т.е. в очередной раз некрасиво.
Но для Гугла этот «миллиард» — тот еще звоночек. Даже если отобьются в этот раз (или найдут «мирный» путь), нет гарантий, что им их любовь к «Яве по-своему» не припомнят еще и еще, так что пилить что-то свое будет понадежнее.
Посмотрим, Гуглу, конечно, виднее, что дороже — потенциальные миллиарды «дяде» при сохранении текущего курса или вполне реальные человеко-годы работы (читай — расходы на разработку) + потеря имиджа (читай — еще расходы) от разработки чего-то нового.
Андройд 1.х я привел как пример. Запуститься старое ПО может и запустится, но, положа руку на сердце — если бы не запустилось, мало бы кто пострадал из широкой публики. WP все же как пример показательнее — и никто не умер, хотя поступил MS тогда вполне по-своему, т.е. в очередной раз некрасиво.
Но для Гугла этот «миллиард» — тот еще звоночек. Даже если отобьются в этот раз (или найдут «мирный» путь), нет гарантий, что им их любовь к «Яве по-своему» не припомнят еще и еще, так что пилить что-то свое будет понадежнее.
Посмотрим, Гуглу, конечно, виднее, что дороже — потенциальные миллиарды «дяде» при сохранении текущего курса или вполне реальные человеко-годы работы (читай — расходы на разработку) + потеря имиджа (читай — еще расходы) от разработки чего-то нового.
нет гарантий, что им их любовь к «Яве по-своему» не припомнят еще и еще, так что пилить что-то свое будет понадежнее
Как нет гарантий, что написанная с нуля реализация не нарушит какой-то хитрый патент, и все твои усилия окажутся потраченными вхолостую. При нынешнем американском законодательстве о патентах, разработчиков можно запереть в бункере и заставить написать что-то с нуля, и со 100%-вероятностью это «с нуля» нарушит с десяток патентов.
Да, вероятно, Google поступила неверно, сделав ставку на Java, а затем дав Oracle купить Sun. Но даже в Google никто не ждал, что Android спустя 10 лет будет покрывать 80% поставок смартфонов, и заводиться на спектре устройств от часов до космических спутников. Ещё пару лет назад, когда Пейджа с Брином спросили, мол, насколько важен Android для Google, они говорили, что не особо он важен, а теперь Пейдж на собраниях инвесторов заявляет, что Android чуть ли не важнейший проект компании. Если бы знали потенциал, то, вероятно, Sun была бы частью Google, но получилось так, как получилось. И я крайне сомневаюсь, что теперь Google будет заниматься архитектурным переписыванием Android ради того, чтобы отбиться от Oracle.
И у меня большие сомнения по поводу миллиардов. Более того, у меня даже в свете нынешней позиции апелляционного суда большие сомнения, что Oracle дело выиграет и получит хотя бы минимальные $150 тыс. за copyright infringement.
Ну будем надеяться, что «Яву по-своему» они отстоят
Даже если не отстоят, и Google дело проиграет просто в пух и прах, то я крайне сомневаюсь, что Oracle будет заинтересована в ликвидации Android. Уж лучше 1% от выручки Android-рынка (который в квартал генерирует около сотни миллиардов долларов), чем ничего от iOS/WP-рынка.
Да я за Android и не беспокоюсь. Понятно, что «киты» договорятся — вопрос лишь в том, кто кому сколько отвалит, а это меня не интересует.
Главное, что меня волнует — это то, что в случае победы Oracle, все мы навсегда похороним надежду на Java, свободную от ограничений. GPL-версия в OpenJDK — не в счет. Она ограничивает не пользователей, но разработчиков.
Я хочу, чтобы была Java, с которой можно делать что угодно — реализовать самому, переделывать, продавать результат переделки или раздавать его даром… Как с C++. Как с Pascal. Как со стандартизованной частью C#… А вот этого в случае их победы не будет.
Не знаю, как вам, а мне неприятно чувствовать, что большая часть моих интеллектуальных достижений находится в руках у коммерсантов, которые в любой момент могут ограничить плоды моих трудов или вовсе свести их на нет.
Главное, что меня волнует — это то, что в случае победы Oracle, все мы навсегда похороним надежду на Java, свободную от ограничений. GPL-версия в OpenJDK — не в счет. Она ограничивает не пользователей, но разработчиков.
Я хочу, чтобы была Java, с которой можно делать что угодно — реализовать самому, переделывать, продавать результат переделки или раздавать его даром… Как с C++. Как с Pascal. Как со стандартизованной частью C#… А вот этого в случае их победы не будет.
Не знаю, как вам, а мне неприятно чувствовать, что большая часть моих интеллектуальных достижений находится в руках у коммерсантов, которые в любой момент могут ограничить плоды моих трудов или вовсе свести их на нет.
Подскажите, как можно настаивать на своей адекватности, заявляя, что нельзя дорабатывать и перерабатывать имеющиеся алгоритмы? Как, по мнению таких «адекватов», происходит прогресс, каждый изобретает свой велосипед с нуля, не только не обращая внимания на имеющиеся наработки, но и специально обходя их стороной? Но это же лютый бред! Такой подход развития прогресса прекрасен лишь для тех, кому на прогресс плевать с высокой колокольни, разве это не очевидно?
Во-первых, речь, насколько я понял, шла не об алгоритмах, а о коде. Во-вторых на адекватность настаивать можно. На честности — нет.
Патентное право устарело. Оно формировалось в те времена, когда изобретателей было мало, они создавали принципиально новые вещи и за каждым охотились коммерсанты, пытаясь присвоить путём промышленного шпионажа эти новинки. Задача патентования в том, чтобы никто не смог без согласия автора использовать его инженерное решение. Это — благородное и очень правильное стремление защитить гениев интеллекта от посягательств на их творческие успехи.
Но в те времена никто и помыслить не мог, что 5% населения планеты вдруг станут «изобретателями» и что для того, чтобы пробиться среди такой бешенной конкуренции и хоть что-нибудь заработать, надо будет сперва отдавать обществу свои изобретения забесплатно, лишь чтобы выделиться среди серой массы других таких же «гениев» и пробиться в бизнес. Никому еще в середине 20-го века не пришла бы в голову лицензия BSD или, тем более, Apache. Слыханное ли дело — отказываться от прав на собственное изобретение — лишь бы только его могли использовать другие! Это ж коммунизм какой-то, прости господи…
Еще одна причина, которой не было тогда, и которая стала исключительно важной сейчас — объем «изобретений». Полвека назад автомобиль разрабатывался весь целиком десятком инженеров в одной компании и в ней же выпускался. Сейчас ни одну серьёзную программу написать «с нуля» невозможно — как минимум вы используете системные API. Поэтому отдать эксклюзивное право на часто используемый код одной компании — значит просто продаться ей в рабство. А люди этого не хотят. Это отлично понимают, скажем, Apple, строя все свои разработки на открытых технологиях и навариваясь исключительно на «верхнем слое». То есть OS X — платная, а вот Darwin, LLVM/Clang, прочие системные библиотеки — с лицензией BSD в основном.
К тому же, хоть конкуренция между теми же производителями автомобилей была жесткая, но я что-то ни разу не слышал, чтобы кто-то кому-то запрещал на основе патента ставить в машину руль, педали или зеркала заднего вида. А Oracle сейчас пытается примерно этим заниматься…
Но в те времена никто и помыслить не мог, что 5% населения планеты вдруг станут «изобретателями» и что для того, чтобы пробиться среди такой бешенной конкуренции и хоть что-нибудь заработать, надо будет сперва отдавать обществу свои изобретения забесплатно, лишь чтобы выделиться среди серой массы других таких же «гениев» и пробиться в бизнес. Никому еще в середине 20-го века не пришла бы в голову лицензия BSD или, тем более, Apache. Слыханное ли дело — отказываться от прав на собственное изобретение — лишь бы только его могли использовать другие! Это ж коммунизм какой-то, прости господи…
Еще одна причина, которой не было тогда, и которая стала исключительно важной сейчас — объем «изобретений». Полвека назад автомобиль разрабатывался весь целиком десятком инженеров в одной компании и в ней же выпускался. Сейчас ни одну серьёзную программу написать «с нуля» невозможно — как минимум вы используете системные API. Поэтому отдать эксклюзивное право на часто используемый код одной компании — значит просто продаться ей в рабство. А люди этого не хотят. Это отлично понимают, скажем, Apple, строя все свои разработки на открытых технологиях и навариваясь исключительно на «верхнем слое». То есть OS X — платная, а вот Darwin, LLVM/Clang, прочие системные библиотеки — с лицензией BSD в основном.
К тому же, хоть конкуренция между теми же производителями автомобилей была жесткая, но я что-то ни разу не слышал, чтобы кто-то кому-то запрещал на основе патента ставить в машину руль, педали или зеркала заднего вида. А Oracle сейчас пытается примерно этим заниматься…
Это отлично понимают, скажем, Apple, строя все свои разработки на открытых технологиях и навариваясь исключительно на «верхнем слое».
Эта та самая компания, которая именно при помощи патентов судится из-за формы телефона и движения рук?
А одно другому вовсе не противоречит. Они одновременно создают себе хорошую базу и репутацию среди разработчиков кода, вкладываясь в опенсоурс и при этом воюют с другими «китами» индустрии. В целом, выхлоп получается положительным. Больше, чем у «тихих, невинных» Microsoft…
Тогда чем же плох Oracle, он вроде тоже против кита воюет, а не против разработчиков?
Разница в том, что Apple запрещает делать по своим патентам вещи, которые делать могут только десять фирм в мире, а мелкие компании/частные разработчики не могут.
А Oracle стремится задавить принципиально всех. JVM — это какие-то несколько тысяч человеко-часов. Это теоретически может сделать даже пара разработчиков.
А Oracle стремится задавить принципиально всех. JVM — это какие-то несколько тысяч человеко-часов. Это теоретически может сделать даже пара разработчиков.
OS X — платная
— Не эксперт по макам, но lolwut?
— Не эксперт по макам, но lolwut?
ну вообще-то они бесплатно выдали только обновление 10.8 до 10.9. Раньше, кажется, рно недорого, но оплачивалось
>Не эксперт по макам, но lolwut?
До 10.9 можно бесплатно обновиться с некоторых предыдущих версий. Отдельно она не распространяется.
А теперь смотрим как получить эти самые «предыдущие версии»:
Mac OS X Snow Leopard (10.6) — $19.99
Mac OS X Lion (10.7) — $19.99
Mac OS X Mountain Lion (10.8) — $19.99
До 10.9 можно бесплатно обновиться с некоторых предыдущих версий. Отдельно она не распространяется.
You can upgrade to OS X Mavericks from Snow Leopard (10.6.8), Lion (10.7) or Mountain Lion (10.8).
А теперь смотрим как получить эти самые «предыдущие версии»:
Mac OS X Snow Leopard (10.6) — $19.99
Mac OS X Lion (10.7) — $19.99
Mac OS X Mountain Lion (10.8) — $19.99
Большая победа для Oracle, и полное поражение всей индустрии ПО…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Oracle выиграла аппеляцию против Google