The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Исполнительный комитет JCP не утвердил модульную систему в Java 9

09.05.2017 22:48

Исполнительный комитет JCP (Java Community Process) отклонил принятие спецификации JSR 376 (Java Platform Module System), в рамках которой развивалось ключевое улучшение платформы Java 9, релиз которой запланирован на 27 июля 2017 года. JSR 376 отражает изменения, подготовленные в рамках проекта Jigsaw, и предлагает принципиально новые для Java средства разбиения программ и JDK на модули.

Против добавления в Java средств для разбиения на модули проголосовало 13 из 23 активных участников комитета. Среди проголосовавших против: IBM, Red Hat, Eclipse Foundation, Hewlett Packard Enterprise, SAP и Twitter. Из участников, голосовавших за принятие JSR 376, можно отметить Intel, Fujitsu, Goldman Sachs, Oracle. В течение 30 дней планируется выставить на голосование обновлённый вариант спецификации, в случае одобрения которого ещё удастся выпустить Java 9 в срок.

По мнению сторонников проекта Jigsaw разбиение кода платформы Java на модули упростит создание, сопровождение и распространение больших приложений, позволив избавиться от наблюдаемых в настоящее время проблем с монолитными JAR и распространением наборов классов. Система модулей даст возможность легко выделять функциональность и формировать настраиваемые конфигурации, адаптируемые как для развёртывания на больших серверах, так и на встраиваемой технике. Модульные приложения, построенные на основе модульной платформы Java, потребуют загрузки меньшего объёма данных и позволят достигнуть более высокой производительности за счёт более эффективной оптимизации специфичных для используемой конфигурации модулей.

Основными противниками принятия JSR 376 стали компании IBM и Red Hat. Остальные в основном присоединились к мнению IBM или проголосовали против, так как среди участников совета не был достигнут консенсус и остаются нерешёнными спорные вопросы. Компания IBM проголосовала против, так как считает, что спецификация ещё не готова для утверждения и требует дополнительной доработки.

Компания Red Hat полагает, что внедрение Jigsaw приведёт к нарушению работы уже существующих приложений и, как следствие, инициирует раскол экосистемы и фрагментацию сообщества: с одной стороны окажутся системы на базе Jigsaw, а с другой все остальные решения, включая Java SE ClassLoader и OSGi. Отмечается также негативное влияние на выпуск Java EE 9, который невозможно будет построить на базе Jigsaw, так как это потребует разорвать обратную совместимость, переносимость и паритет в функциональности с прошлыми выпусками спецификаций Java EE. Оппоненты утверждают, что Red Hat пытается защитить уже поставляемую в платформе WildFly собственную систему загрузки модулей JBoss Modules, которую трудно будет сохранить в неизменном виде после внедрения Jigsaw.

  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Выход Java 9 переносится на июль 2017 года
  3. OpenNews: Java 9 переносится на 2017 год
  4. OpenNews: Обнародован график подготовки Java 9
  5. OpenNews: Новшества Java 9
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/46519-java
Ключевые слова: java
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (131) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Владислав Никифоров (?), 23:06, 09/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Java давно не торт. Мы всем отделом (200 человек) переписали наш софт на Python и сэкономили за год $1.5 млн. Python выигрывает в скорости разработки, гибкости и поддержке.
     
     
  • 2.5, Отражение луны (ok), 23:38, 09/05/2017 [^] [^^] [^^^] [ответить]  
  • –18 +/
    В свою очередь нода выигрывает у питона. Но с первоначальным утверждением согласен.
     
     
  • 3.73, anonymous (??), 15:32, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    а PHP выигрывает у ноды
     
     
  • 4.80, 123452345345 (?), 20:36, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +8 +/
    А Perl выигрывает у всех выше перечисленных.
     
     
  • 5.117, Vitaliy Yakovchuk (?), 21:08, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Ну и конечно Java выигрывает у perl :)
     
     
  • 6.132, anonymous (??), 10:17, 15/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в твоих бредовых фантазиях она и у машкода выигрывает
     
  • 6.133, scorry (ok), 11:57, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Круг замкнулся, как водится. Камни-ножницы-бумагу никто не отменял!
     
  • 2.13, Аноним (-), 00:19, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Переписали бы на Ruby, выиграли бы ещё больше, так ещё и были бы готовы работать на американском или немецком рынке веб-разработки :)
     
     
  • 3.15, Lolwat (?), 00:33, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Тут ruby давно не модно. Все хотят nodejs.
     
     
  • 4.16, Lolwat (?), 00:34, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Тут ruby давно не модно. Все хотят nodejs.

    Тут = USA

     
     
  • 5.19, Аноним (-), 01:07, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Про всех статистика не показывает https://trends.google.com/trends/explore?cat=5&date=all&q=/m/0505cl,/m/06y_qx,/m/0bbxf89
     
     
  • 6.20, о6какатрон (?), 01:19, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    https://trends.google.com/trends/explore?cat=5&date=today 12-m&q=/m/0505cl,/m/06y_qx,/m/0bbxf89,phyton

    так более информативно

     
     
  • 7.23, Аноним (-), 01:27, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > так более информативно

    я не знаю, кто такой phyton, но ясно, что за пределами РФ на Python веб разработки почти нет и не будет :)

     
     
  • 8.45, . (?), 04:49, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ясно только то, что _ты_ за пределами РФ никогда не был - ... текст свёрнут, показать
     
     
  • 9.46, Аноним (-), 04:55, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ага Именно поэтому сижу за рабочим местом если в РФ, то ночью и мониторю ветк... текст свёрнут, показать
     
  • 8.50, SkyNet (??), 08:12, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Моня, Мир таки не Одесса, так можно и утро пропустить, на Привозе https www ti... текст свёрнут, показать
     
  • 8.77, northbear (??), 16:58, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Чушь По востребованности более чем сравнимо js nodejs По фриланс-биржам это ... текст свёрнут, показать
     
  • 6.71, amonymous (?), 14:29, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Вот так ещё интереснее:
    https://trends.google.com/trends/explore?cat=5&date=today%2012-m&q=%
     
  • 3.24, Аноним (-), 01:44, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ахаха, руби в данный момент используется ТОЛЬКО для быстрого выпуска прототипов (из-за низкого порога вхождения), а потом... потом обратно на жава/скала/го. С разморозкой
     
     
  • 4.28, Аноним (-), 02:02, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    вот про низкий порог вхождения на руби обычно говорят те, кто в него так и не смог войти.... Эффективный код на руби - это функциональный стиль. Хоть и под истинно объектным языком. Под него мозги перестравить надо.

    А вот то, что на нём удобно писать - это да.

     
     
  • 5.39, Аноним (-), 04:13, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вы оба правы и не правы. На Ruby очень удобно писать dsl, это поистине замечательно делает твой код лаконичным и красивым и супер читабельным. Но дьявол кроется в деталях. После того как ты не трогал проект долгое время и всё что ты налабал уже выветрелось из головы, что бы понять что делает твой замечательный dsl тебе нужно пересмотреть дофига кода. Притом чем более запутанный(магический) dsl вы написали тем больше нужно приложить усилей. И тут встает вопрос плох или хорош dsl, а вот это уже зависит от того как вы его написали, размера и сложности проекта. Именно поэтому сейчас многие переходят на Go который простой как табуретка. Ну и немного не по теме, ruby для перестройки мышления в функциональную парадигму не лучший выбор.
     
     
  • 6.41, Аноним (-), 04:27, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> После того как ты не трогал проект долгое время и всё что ты налабал уже выветрелось из головы,

    Это не Хаскель. Если код написан нормально, а не в последнюю ночь перед сдачей проекта (у меня сейчас вечер, если что :-) ), то нормально он поддерживается. Надо знать принципы работы руби, тогда и найти где конкретно реализована та или иная фича DSL - не сложно.

    На счёт go, то вроде как рекомендация идти на rust. Даже попытки ML на него перетащить уже есть - http://weld.stanford.edu (проект от бывших питонистов-скалистов)

     
  • 6.42, Аноним (-), 04:33, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и немного не по
    > теме, ruby для перестройки мышления в функциональную парадигму не лучший выбор.

    Чем плох? Тем что блок - только одна функция? Традиционную схему преобразования данных на map/select/reduce на нём очень хорошо показывать. Концепция отложенных вычислений с неявными callback - тоже хорошо демонстрируется.

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

     
  • 6.48, Аноним (-), 07:18, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >На Ruby очень удобно писать dsl

    Мда. Понятно, насколько крут ваш руби. В то время как все остальные уже перешли на PEG-подобные-движки, и пишут dsl на этих движках (которые покрывают 95% задач), вы все еще пишите на руби.

    google://parsing expression grammar

    Не благодари.

     
     
  • 7.49, Аноним (-), 07:39, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > google://parsing expression grammar

    сам понял, что написал? Разницу между DSL и DSEL слышал?
    Я не тот Аноним, который написал о DSL в первый раз, но опыт использования и написания своих DSL/DSEL на руби действительно имею. Впрочем и опыт написания парсеров на Ragel и ANTLR тоже имею. Собрать на руби DSEL действительно удобно и быстро в силу гибкости языка. Сравниться с ним может разве что скала, но у неё свои проблемы.

     
     
  • 8.51, Аноним (-), 08:41, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    1 https en wikipedia org wiki Parsing_expression_grammar 2 http dl acm org... текст свёрнут, показать
     
     
  • 9.53, Аноним (-), 09:54, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно, PEG на руби пишется красиво https github com nathansobo treetop... текст свёрнут, показать
     
  • 6.97, Вареник (?), 10:18, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > На Ruby очень удобно писать dsl, это поистине замечательно делает твой код лаконичным и красивым и супер читабельным.

    WriteOnlyCode получается. На Скале с этим каждая попробовавшая команда обжигается. DSL сносит крышу и у каждое либы получается свой собственный язык.

     
     
  • 7.114, Аноним (-), 20:24, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не надо сравнивать скалу и руби. В случае скалы большая часть кода - write only
     
  • 2.30, qsdg (ok), 02:08, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +8 +/
    А мы (в Google) -- наоборот, переписали с Python на Java, и очень рады, что теперь не нужно писать (и самое главное -- мэйнтэйнить) десятки юнит-тестов на каждый юнит, т.к. Java статически типизирована. Раньше test/code ratio по строчкам кода доходил иногда до трёх. В Java -- около единицы теперь.
     
     
  • 3.31, qsdg (ok), 02:09, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    PS: А скорость разработки страдает только у тех, кто не умеет пользоваться современными IDE.
     
     
  • 4.40, Аноним (-), 04:16, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > PS: А скорость разработки страдает только у тех, кто не умеет пользоваться
    > современными IDE.

    Отчасти вы правы, idea очень сильно помогает, но эта ситуация не только у java.


     
  • 3.55, слон (?), 10:41, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >А мы (в Google) -- наоборот, переписали с Python на Java

    почему не Go или Dart?

     
     
  • 4.58, Аноним (-), 10:58, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Потому что го и дарт для страдания конкурентов, а им самим надо чтобы просто работало
     
  • 4.95, Вареник (?), 10:13, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>А мы (в Google) -- наоборот, переписали с Python на Java
    > почему не Go или Dart?

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

     
  • 3.135, Аноним (-), 22:33, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В Java -- около единицы теперь.

    А с какой стороны?

     
  • 2.43, Аноним (-), 04:40, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ага, особенно умиляет отсутствие упоминания конкретного интерпретатора — вы хоть, надеюсь, не будете утверждать, что что-то сэкономили за счёт использования апстримного питона?
     
  • 2.78, Comdiv (ok), 18:09, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Можете рассказать, какова была методика оценки экономии?
     
  • 2.99, Вареник (?), 10:24, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Java давно не торт. Мы всем отделом (200 человек) переписали наш софт
    > на Python и сэкономили за год $1.5 млн. Python выигрывает в
    > скорости разработки, гибкости и поддержке.

    Многократный бред и победа НЛП над разумом.

    На питоне больше писанины тестов, больше дебагинга, хуже с фреймворками.
    Где-то лучше с либами (научный софт), где-то хуже (серверный).

    Т.е. вы поменяли шило на мыло, при этом вместо рефакторинга - все переписывая.
    Но руководство проекта так всем запудрило мозги, что это расточительство сочли "экономией", да еще с подсчитанной цифрой (как будто рефакторинг без переписывания вышел бы дороже, что абсурд).

     
  • 2.118, КО (?), 21:36, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Экономия 625 баксов в месяц на программиста. Дешевы же програмеры на Питоне.
     
  • 2.134, Аноним (-), 22:28, 16/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы сделали дополнительную работу - "переписали наш софт" и сэкономили?
    Вы, все 200 человек, приплачивали за возможность писать на питоне?
     

  • 1.3, Аноним (-), 23:27, 09/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Забавно смотреть на попытки расшевелить то что двигаться не способно от рождения. Раскол уже на принятии решения, надо думать что потом будет если примут. Потом думаю будет Go или Rust.
    С другой стороны, жалко немного Жабу. Многому она меня научила. Свой первый серьезный проект я сделал как раз на Java.
     
     
  • 2.10, Crazy Alex (ok), 00:13, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если они не угадают - будет не Go и не Rust, а .NET, так что лучше уж пусть осторожничают
     
  • 2.25, Аноним (-), 01:49, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Судя по массовому вовлечению разработчиков со стороны создателей языка и дикому восторгу хипстеров от айти, скорее таки go.
     
     
  • 3.96, Вареник (?), 10:15, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Судя по массовому вовлечению разработчиков со стороны создателей языка и дикому восторгу
    > хипстеров от айти, скорее таки go.

    Ужас. Лучше уж .NET, если не Java.

     
  • 2.100, Igor1986 (?), 10:27, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Забавно смотреть на попытки расшевелить то что двигаться не способно от рождения.
    > Раскол уже на принятии решения, надо думать что потом будет если
    > примут. Потом думаю будет Go или Rust.
    > С другой стороны, жалко немного Жабу. Многому она меня научила. Свой первый
    > серьезный проект я сделал как раз на Java.

    Да не переживай ты так за Java, она будет живее всех остальных живых!!!

     

  • 1.4, mimocrocodile (?), 23:31, 09/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    сколько они лет уже этот jigsaw теребят?
    микрософт уже успел .net опенсорснуть и под линукс выпустить.
    воистину https://en.wikipedia.org/wiki/Design_by_committee
     
     
  • 2.26, Avator (ok), 01:59, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Можно поинтересоваться причем тут .Net.
    При том что под Linux похоже его используют три калеки (и не так уже  важно OpenSource он или нет).
     

  • 1.6, Аноним (-), 23:47, 09/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Как на JVM выполнить аналог питоновского :
    python -m SimpleHTTPServer 8080
     
     
  • 2.11, Crazy Alex (ok), 00:14, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Не надо ездить на карьерном самосвале за хлебом. На легковушке, впрочем, тоже щебень возить не стоит.
     
     
  • 3.17, Аноним (-), 00:53, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В смысле сервера не надо писать на Java? Да вы не Crazy а Mad или Nut.
     
     
  • 4.27, Crazy Alex (ok), 01:59, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В смысле джава - не для "simple server". И вообще не для simple. А вот в сложных вещах ей самое место.
     
     
  • 5.38, Аноним (-), 03:54, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ну и дурик ты.
    groovy -l 80 SimpleWebServer

     
     
  • 6.56, Crazy Alex (ok), 10:46, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Java от Groovy не отличаем?
     
     
  • 7.59, Аноним (-), 10:59, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Java от Groovy не отличаем?

    Вопрос был про jvm, а не именно про жабу, так что проходи мимо

     
     
  • 8.62, Crazy Alex (ok), 11:53, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хм, да, чего это я Впрочем, на кой так извращаться - всё равно не понимаю Энте... текст свёрнут, показать
     
     
  • 9.65, Аноним (-), 12:55, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Твоё узкое мировоззрение не позволяет адекватно смотреть на факты... текст свёрнут, показать
     
     
  • 10.69, Аноним (-), 14:05, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Часто повторяемые мантры жабка JVM НЕ ТОРМОЗЯТ еще не факты и на реальность не... текст свёрнут, показать
     
     
  • 11.79, iZEN (ok), 20:35, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Какими конкретными программами на Java ты пользовался ... текст свёрнут, показать
     
     
  • 12.127, symply (ok), 07:10, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Например, Windchill ... текст свёрнут, показать
     
  • 6.126, й (?), 01:57, 13/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Caught: java.io.FileNotFoundException: /Users/me/SimpleWebServer (/Users/me/SimpleWebServer)
    Groovy Version: 2.4.11 JVM: 1.8.0_131
     
  • 5.52, Аноним (-), 09:39, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Типичный Java программист. Нехрена не знает языка, зато считает что именно на нем должны писаться сложные вещи.
     
     
  • 6.63, Crazy Alex (ok), 11:55, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я сишник, мне можно :-) А говорю о том,ч то вижу кругом, в кровавых энтерпрайзах... Большое пишется либо на джаве, либо на C#, всё остальное и 10% хором не наберёт.
     
     
  • 7.72, QuAzI (ok), 15:01, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты, конечно, про большие распилы, а не ехать?
     
     
  • 8.75, Crazy Alex (ok), 16:41, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я про ехать Джава - довольно простой, но громоздкий язык, и всё там такое же Н... текст свёрнут, показать
     
  • 4.102, Igor1986 (?), 10:30, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > В смысле сервера не надо писать на Java? Да вы не Crazy
    > а Mad или Nut.

    на Java стоит писать сервера!!! Как бы там не гавкали, Java всем покажет ещё зубы, на что она способна!!!!


     
  • 2.47, лютый жабист__ (?), 06:46, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +5 +/
    "Как на JVM выполнить аналог питоновского"

    Написал бы, что оно делает. Ну, вебсервер на 8080 порту запускается и что он делает? Ничего? И?!

    Формально, в javaEE пустой сервлет тоже не надо кодить, только проект создать в IDE и артифакт. Несколько секунд. Этим надо гордиться?

    Я лично жабку люблю не за пустой вебсервер за 1 секунду, а за то, что я за несколько часов могу сделать backend который будет сервить данные из базки под терабайт для нескольких килоклиентов с временем ответа в единицы милисекунд. Без ЛАМПовых костылей в виде memcached, redis итд И что когда моя контора дорастет до хайлоада, я на той же жабе буду делать распределенные системы. Может и питон это может, флаг в руки, мне не жалко.

     
     
  • 3.74, anonymous (??), 15:44, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > могу сделать backend который будет сервить данные из базки под терабайт для нескольких килоклиентов с временем ответа в единицы милисекунд. Без ЛАМПовых костылей в виде memcached, redis итд И что когда моя контора дорастет до хайлоада, я на той же жабе буду делать распределенные системы.

    рецепт дадите? может я что-то не знаю про жабу... чем вы замените кеши типа memcасhed/redis? как вы впилите горизонтальное масштабирование? я создаю горизонтально масштабируемые системы но не на жабе, можете объяснить как это сделать на жабе простыми словами и конкретными примерами?

     
     
  • 4.83, Dmitry77 (ok), 22:54, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Задавайте конкретные вопорсы вам ответят.
     
     
  • 5.104, anonymous (??), 10:33, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    конкретные вопросы как храните данные, как масштабируете хранение данных, как добаляете сервера хранения данных в подсистему хранения, как исключаете сервера хранения данных из подсистемы хранения данных, как перераспределяете данные в подсистеме хранения данных?

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

    SQL со своими велосипедами роутинга и шардирования но с транзакциями и локами?
    mongodb без транзакций и локов но с шардированием?
    cassandra с brain split?
    что-то свое волшебное?

     
     
  • 6.109, Igor1986 (?), 11:09, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > SQL со своими велосипедами роутинга и шардирования но с транзакциями и локами?

    В наши дни пока SQL играет немаловажную роль, он вроде не такой уж сильно загроможденный, даже XQuery XPath почему-то больше времени занимают, у них свои характеристики работы.


     
  • 6.111, лютый жабист__ (?), 11:51, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > конкретные вопросы как храните данные, как масштабируете хранение данных, как добаляете
    > сервера хранения данных в подсистему хранения, как исключаете сервера хранения данных
    > из подсистемы хранения данных, как перераспределяете данные в подсистеме хранения данных?

    Это не конкретные вопросы. Данные в жабе не храним, ей их обрабатываем. Упарываться по транзакционности стараемся не. 8) Поэтому в основном Монго.

    Кстати, для особенно кровавых ынтырпрайзщиков в жабе есть спецификация JTA на тему распределенных транзакций. Можно взять данные в Postgres, обработать, положить в Oracle в рамках атомарной операции. На Пистоне так можно?

     
     
  • 7.113, anonymous (??), 13:03, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    те ваш ответ JTA это серебрянная пуля для hiload, так?
     
  • 4.110, лютый жабист__ (?), 11:43, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >чем вы замените кеши типа memcасhed/redis

    В качестве локального кеша банальный HashMap просто разрывающе быстрее и удобнее.
    FastUtil ещё быстрее, заметно экономнее с ОЗУ с примитивными типами.

    Распределенный кеш - Infinispan есть в моём AS. Куча других нативных решений.

    В чём заключается незаменимость redis? Кеш как внешнее решение это просто нонсенс.

     
     
  • 5.112, anonymous (??), 13:02, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >Кеш как внешнее решение это просто нонсенс.

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

     
  • 4.128, yo (?), 03:46, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Описанная конфигурация - не highload. Распределять и масштабировать (в JVM) ничего не нужно на таких нагрузках. Кешей хватает внутренних. А все упомянутые вами инструменты появляются на более высоких нагрузках, и там у Java все как у всех. Никакой магии.
     
  • 2.54, MVK (??), 10:31, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    HttpServer server = HttpServer.create();
    server.bind(new InetSocketAddress(8080), 0);
    server.createContext("/", new SomeHandler())
    server.start();
     
     
  • 3.66, Аноним (-), 12:57, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Думал, запустите этот сервер на питоне. Он там еще сервит файлы в текущй папке.


     
     
  • 4.70, Ан (??), 14:22, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Проще говоря занимается не тем чем должен. :)
     
     
  • 5.76, Аноним (-), 16:49, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>> python -m SimpleHTTPServer 8080
    >> Он там еще сервит файлы в текущй папке.
    > Проще говоря занимается не тем чем должен. :)

    А чем должен заниматься _простой_ httpserver? Неужели только жрать ЦПУ и раму, но абсолютно ничего не делать? o_O


     
  • 2.119, КО (?), 21:40, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    $CATALINA_HOME/bin/startup.sh :)
     

  • 1.7, Аноним (-), 23:51, 09/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Перевожу бекенд с Java на D, ИМХО в плане С-синтаксиса альтернатив нет. А жаль
     
     
  • 2.12, Crazy Alex (ok), 00:16, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вау, и как? Неплохо было бы услышать о практическом опыте. В идеале - в виде статьи...
     
     
  • 3.18, D (?), 01:03, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    D торт, на мой взгляд незаслужено замалчиваемый, для веб есть vibe d который уде... большой текст свёрнут, показать
     
     
  • 4.22, Ан (??), 01:25, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC

    Там есть весьма интересная штука Rocket. Хотя он написан с использованием фич из nightly. А сама замудрённость не проблемна как мне кажется.

     
     
  • 5.34, D (?), 02:36, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Пробовал Rust - замудреный, но хотелось бы возможности в D иметь подсчет ссылок вместо GC
    > Там есть весьма интересная штука Rocket. Хотя он написан с использованием фич
    > из nightly. А сама замудрённость не проблемна как мне кажется.

    Rust многословен, на то время что я его смотрел не было аналогов mixin, static if из D

     
  • 4.29, Crazy Alex (ok), 02:04, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что такое D я и сам могу рассказать :-) Интересен опыт его внедрения в реальной системе, о описанием плюсов, граблей и способов их обхода.

    А так - да, пул потоков из двадцати строчек, мини-орм из сотни и так далее - писал, и было на редкость приятно. Вот vibe.d как-то не оценил, роутер был какой-то совершенно убогий. Но давно это было, там наверняка давно допилили его. По сравнению с плюсами, конечно, небо и земля - писать проще, гибкость больше. Один UFCS чего стоит.

     
     
  • 5.33, D (?), 02:34, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Все что нужно есть так или иначе, на крайняк можно прикрутить Cишную-либу.

    Я бы не назвал это граблями, скорее неудобства и отсутсвия опыта.

    В реальной системе у нас используется как сетевые демоны, в этом плане стандартная библиотека неудобна, std.socket построен на эксепшенах доступен только select из-за кроссплатформенности, так как у нас на серваках линукс, кросплатформенности не требуется, в качестве сетевого стека используется небольшая обертка над epoll

    Для конкурентности и распаралеливания std.(concurency | parallelism) немного не удобны
    нужно помнить если распаралеленый блок, не забывать о переменных за пределами блока (распаралеленые блоки - отдельные потоки) thread local накладывает дополнительные неудобства с передачей данных между потоками можно конечно юзать префикс gshared - что-бы глобально, как в сишечке - но очень не советуется. Локи опять же вручную, правда мютекс подобных локов есть блок

    synchronized (someMutex)
    {
      ...
    }


    Так же немного не хватает в стандартной библиотеке нормальной работы с Posix-сигналами например как Go

    Стандартная некоторая часть стандартной либы не реализована нативно, часто тянет за собой
    libcurl, libssl и т.д. что пичалит лишними зависимостями (перфекционизм =)

    > Вот vibe.d как-то не оценил, роутер был какой-то совершенно убогий

    Ранее для веба использовался питонячий Werkzeug/Flask, и после перехода на vibe.d вначале был запилен собственный роутер, а в более поздних проектах привык к встроеному в vibe.d свои задачи вбольшинстве случаев он решает (нет роутинга для поддоменов)

    А вот вот с шаблонизатором (diet) я так и не смирился, не хватает наследования - написал свой jinja2 подобный, шаблоны компилятся вместе с проеком =)

     
     
  • 6.36, Crazy Alex (ok), 02:53, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Хм, ясно, спасибо
     
  • 6.94, Вареник (?), 10:06, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Интересный эксперимент. Но после Вас все это придется переписывать, рано или поздно.

    Как это обычно бывает. Посмотрят на количество велосипедов и...

     

  • 1.8, vitalif (ok), 23:55, 09/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    jigsaw это наконец-то разделяемые библиотеки для явы?

    блин, да дайте две, нет, дайте стопицот!!! зачем отменили, гады!!!

     
     
  • 2.14, Sw00p aka Jerom (?), 00:20, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    чтобы бардака как в случае js не было
     
     
  • 3.21, Ан (??), 01:21, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Там как раз бардак начался из-за отсутствия стандарта.
    И Java судя по статье в не меньший бардак способна скатиться учитывая JBoss Modules, OSGi.
     

  • 1.9, Аноним (-), 00:12, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Java - серьезный продукт для серьезных решений.
    Никаких недоделок не должно быть.
    За это я его и уважаю и буду сидеть на нем еще 100500 лет  ))
     
     
  • 2.61, Аноним (-), 11:43, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    ... кроме тех, которые нужны для совместимости
     

  • 1.44, Аноним (-), 04:45, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё правильно сделали. Что Jigsaw — зашквар, стало ясно уже когда при обсуждении спецификации полностью проигнорировали OSGI. Рейнхольда — на мыло!

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

     
     
  • 2.57, Аноним (-), 10:55, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    так Oracle вроде как проголосовал "ЗА". Позиция RedHat в принципе понятна, им придется пилить прослойку для совместимости с JbossModules (если они именно "развалятся" из-за jigsaw). А вот позицию IBM еще бы понять... Скорее всего, там тоже что-то не так с каким-то из их продуктов
     
     
  • 3.60, Аноним (-), 11:39, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Естественно ЗА , - кто в здравом уме признается в некомпетентности своих разраб... большой текст свёрнут, показать
     
     
  • 4.64, Аноним (-), 12:03, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    хз, я читал и положительные и отрицательные отзывы на этот jigsaw. нужно оно в таком виде или нет - сказать сложно. да и большинства разработчиков все эти недостатки коснуться не должно. в любом случае, если его улучшат, пусть даже ценой задержки релиза - я не против. а если его выкинут... что тогда вообще в java9 останется?
     
     
  • 5.68, Аноним (-), 13:41, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    "Большинство разработчиков" обнаружат, что

    1. setAccessible не работает
    2. Unsafe накрылся медным тазом (а вместе с ним и все либы, которые его используют)
    3. Ресурсы из других модулей не читаются
    4. bootclasspath исчез *без какой-либо альтернативы* (вместе с rt.jar)
    5. Встроенные класслодеры больше не наследуются от URLClassLoader

    И выключат jigsaw куда-подальше (если будет соответствующий переключатель). Или останутся сидеть на Java 8. Единственная полезная фича jigsaw - возможность изоляции модулей друг от друга. Но ни всего вышеперечисленного, ни множества других багов (см. ссылку) оно не стоит.

     
  • 2.93, Вареник (?), 10:00, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Интересно, а почему голосование происходит только сейчас? Либо Оракл просто использует
    > эту кашу как предлог не мержить ветку jigsaw (т.е. решение не
    > релизить его было принято уже давно), либо у них всё так
    > плохо с коммуникацией внутри коммитета, что это уже не смешно.

    Архитектурные решения были приняты два-три года назад, но откатить их решили когда вся JSR имплементирована. Это что-то эпичное.

     

  • 1.67, iZEN (ok), 13:29, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Модуль в Java - это .class файл, бинарник. Ничего выдумывать не надо. Всё остальное - перепаковка.
     
  • 1.81, Igor1986 (?), 21:15, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Сколько паники вокруг Java 9 и Jigsaw!!! Понять позицию некоторых компаний, как Red Hat можно, что они боятся, что из-за больших изменений в Java их системы перестанут работать или будут работать, но с нарушением. Лично я в Java не разочарован, буквально недавно "переселился" в Eclipse, там лучше чем в NetBeans, я очень сожалею, что раньше не перешел, Eclipse сказка в большей степени, Eclipse Foundation не отстает. Не знаю, кто из вас всех "обновились до jdk8u131, jdk8u121 очень даже тоже хорошо работает. Я не думаю, что в один миг мир откажется от той версии Java синтаксиса, который применялся в Java  6, 7, 8. Я планирую ещё надолго задержаться в Java, в Java есть немало плюсов, немалое количество компаний до сих пор Java применяют, потому как взять на свои (то есть их плечи) внезапно пересесть с Джава на Питон это очень дорогое удовольствие по деньгам и громадным затратам трудового времени. Я так понимаю, что поскольку я в Eclipse, надо будет следить за позицией Eclipse Foundation, каковы будут их меры по обеспечению совместимости с Java 9, я бы советал большинству не паниковать касаемо Java 9, приспосабливаться нужно ко возможным изменениям.
     
     
  • 2.84, Dmitry77 (ok), 23:05, 10/05/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    одно из главных проимуществ java - обратная совместимость. вы можете взять класс скомпилированный 20 лет назад и запустить на современной JVM. "приспосабливаться" - это значит ценность в java заметно уменьшится.
     
     
  • 3.86, лютый жабист__ (?), 08:29, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > одно из главных проимуществ java - обратная совместимость. вы можете взять класс
    > скомпилированный 20 лет назад

    Есть официальная статистика скольким это надо, запускать классы 20летней давности?

    "главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы совсем в другом.


     
     
  • 4.88, Igor1986 (?), 09:18, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
    >> скомпилированный 20 лет назад

    Доброго времени суток!!! Дмитрий(Dmitry77) просто приводил основные плюсы, что Java в отличие от .NET позволяет запустить программный код 20-ти летней давности, Dmitry77 не имел ввиду, что мы все должны застрять в ностальгии по временам, когда Java была широко совместима с запуском программ, Майкрософтовский .NET не может похвастаться тем, что можно запустить многолетней давности программы. Если на Windows XP Джава позволяла запустить программы более позднего поколения, а .NET требует более новой Виндоус, чтобы установиться как таковой.

    > Есть официальная статистика скольким это надо, запускать классы 20летней давности?

    Статистики точной никто не сможет дать, скольким нужно запускать программы 20-летней давности, от себя обращаясь(меня зовут Игорь) скажу следующее: при первой возможности перехожу на очередные выпуски jdk8u..., которые зачастую устраняют уязвимости и прочие проблемы, не надо пытаться вернуться на Java 6,7, желательно "обитать" сейчас в Java 8, она ввела немало нового, но при этом сохранила возможность запускать программы выпущенные 2004-2009 годами, обращаю Ваше внимание, что JVM(Виртуальная Машина Java) за последние годы не раз подвергалась переработкам и изменениям, я думаю, что немалое количество новых и нынешних(я тоже) Java Developers будут "включать" средства и библиотеки с учётом изменений, которые неизбежно будут вводиться в Java 9.  

    > "главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы
    > совсем в другом.

    У "жабы"(Java) плюсов и других много, Java подходит даже в тех областях бизнес-коммерции, где Python и особенно С++ неуместен. Техсопровождение не такое сильно затратное. Те, кто тут говорят про Dart, Go и Rust - эти языки пригодны сейчас в том, в отношении чего они применяются, может область их применения со временем расшириться, я только ЗА.

     
  • 4.89, Igor1986 (?), 09:40, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я даже признаю и вижу, что Java "нуждается" в свежем глотке новизны, НО... но это не значит, что ORACLE перечеркнет всё, за счёт связанного на Java API работало и запускалось.

    Я обязательно буду отслеживать и наблюдать за Eclipse Foundation, каковы будут их меры и действия касаемо предвещаемых "Jigsaw улучшений" и модульности Java 9.

    Товарищи не паниковать!!!

     
  • 4.92, Вареник (?), 09:55, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> одно из главных проимуществ java - обратная совместимость. вы можете взять класс
    >> скомпилированный 20 лет назад
    > Есть официальная статистика скольким это надо, запускать классы 20летней давности?
    > "главное проимущество" по идее, это то что надо большинству. Соответственно, плюсы жабы
    > совсем в другом.

    Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с написанием (или переписывать на новое API, или заново отлаживать, с новыми глюками) - не каждому бизнесу понравится. С#, Qt, Python считают нормальным переписывания, Java для тех кто ценит уже потраченные усилия.

     
     
  • 5.120, лютый жабист__ (?), 05:32, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
    > написанием (или переписывать на новое API, или заново отлаживать

    Давай не будем передергивать и искажать. Ранее было сказано про код 20 летней давности в СКОМПИЛЕННОМ виде. Я далёк от больших ынтырпрайзов, но по прежнему уверен, что 20летний JAR это не необходимость, а просто кусок мамонтового Гэ, от которого потеряли сорцы и/или документацию.

    На "главный плюс жабы" ваще не тянет. Рефакторинг полезная штука, хоть и стоит денег.


     
     
  • 6.121, Igor1986 (?), 09:15, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
    >> написанием (или переписывать на новое API, или заново отлаживать

    Далеко не каждому в кайф переписывать заново API(для не знающих что это такое, - Application Programming Interface - интерфейс прикладного программирования), сколько бы разработчику ни заплатили за написание новой lib (библиотеки), разработчик не может гарантировать, что даже в хорошо и благополучно написанной библиотеке не будет крахов или каких-то других проблем.

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

     
  • 5.122, Igor1986 (?), 10:16, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Смотря сколько у вас кода. Реинвестировать каждые 3-5 лет суммы, сравнимые с
    > написанием (или переписывать на новое API, или заново отлаживать, с новыми
    > глюками) - не каждому бизнесу понравится. С#, Qt, Python считают нормальным
    > переписывания, Java для тех кто ценит уже потраченные усилия.

    Знаешь, у меня складывается впечатление касаемо C#, Qt, Python что там одни садо-мазохисты, которые любят постоянно что-то переписывать, переиначивать.  

    Java более длительно не изменяющаяся, но и в этом есть плюс, мне не нужно без конца перестраиваться на новый выпуск с учётом нововведений как в случае у тех, кто с Python работает. Java мне даёт постоянство в её применении, большинство библиотек, включая Swing(Metal UI) а также SWT и JFace(IBM/Eclipse Foundation) тоже не изменяемы, я могу без опасения на них GUI писать.

    Я со своей стороны не тороплюсь делать выводы о Jigsaw в Java 9, хоть уже успел просмотреть JSR 376 на openjdk.java.net и уже видел The Java Language Specification Java SE 9 Edition(спецификация к загрузке предлагается в PDF) и могу сказать, что Java SE 9 не такая уж и плохая как о ней говорят, да и ещё, грядут изменения касаемо синтаксиса MANIFEST.MF, JSR 376 чаще упоминает не столько MANIFEST.MF сколько INDEX.LIST.  

     
     
  • 6.124, Аноним (-), 20:01, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • +/

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

    Ох уж эти жабисты. Во первых, обратную совместимость в питонах никто не ломает.
    Во вторых, какие-то уж очень странные у вас питоны. Вы точно о ЯП, а не об одной из кучи библиотек?
    Ну и наконец, сравнение фиолетового с яблочным.
    Питон – это в первую очередь скрипты и прототипы, от силы на несколько тысяч строк.
    Это как с мултитулом. Подкрутить им что-то по мелочи будет быстрее, чем сбегать за ящиком с инструментами, но вот чинить или разбирать что-то всерьез – увольте. Хотя любители находятся, да.

     
  • 4.105, Вареник (?), 10:38, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Есть официальная статистика скольким это надо, запускать классы 20летней давности?

    Каждая платформа обрастает экосистемой библиотек. Если либа не изменялась 5-10 лет - это не значит что она устарела, она может быть даже единственным (уникальным) решением какой-то проблемы.

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

    Но большие корпорации, уровня IBM-Oracle, не любят кидать на деньги сами себя, поэтому используют стабильную платформу - JDK.

     
     
  • 5.107, Igor1986 (?), 10:53, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Но большие корпорации, уровня IBM-Oracle, не любят кидать на деньги сами себя,
    > поэтому используют стабильную платформу - JDK.

    Ты всё правильно сказал относительно IBM и ORACLE, JDK как-никак "рулит", без JDK никуда!!!

     

  • 1.82, Igor1986 (?), 21:27, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В дополнение скажу, не только с Джава на Питон, но и на другие языки. Рэд Хэт уж точно не факт что примется потратить время на переписывание своих систем.
     
  • 1.85, Dmitry77 (ok), 23:07, 10/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Зачем  нужен Jigsaw, когда есть OSGI ?
     
     
  • 2.87, Igor1986 (?), 08:41, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Дмитрий, я тоже с Вами согласен, есть OSGi, прикол ещё в том, что этот OSGi упоминается и в Eclipse. Судя по всему, ORACLE думает, что разбивка на модули JRE и JDK "облегчит" техническое сопровождение как новых выпускаемых программ на Java Platform так и уже не один и не два года ныне работающих программ. Дмитрий, мне будет очень интересно как Eclipse Foundation будет вести политику по отношению таких "неблагоприятных" изменений, введение которых может поставить под угрозу нормальное функционирование большинства того, что есть в Eclipse IDE(вне зависимости от отдельно выбранного дистрибутива, как для Java, так и для С/С++, и прочее), поскольку для запуска и нормального функционирования таких как Eclipse IDE и даже тем, кто до сих пор с NetBeans необходим JDK. Почему я заговорил об этом, потому что сильные изменения могут нехорошо сказаться на всю Eclipse Platform. Но я думаю, что сейчас пока не стоит паниковать из-за Java 9, первое что могу сказать, - размер загружаемого JDK с может увеличиться со 190 МБ до 200 с копейками МегаБайт, ORACLE сама применяет в своих продуктах Java, думаю они там не дураки, чтобы в один миг отказаться от того, что было в Java 7, 8.
     
     
  • 3.115, iZEN (ok), 20:35, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >[оверквотинг удален]
    > дистрибутива, как для Java, так и для С/С++, и прочее), поскольку
    > для запуска и нормального функционирования таких как Eclipse IDE и даже
    > тем, кто до сих пор с NetBeans необходим JDK. Почему я
    > заговорил об этом, потому что сильные изменения могут нехорошо сказаться на
    > всю Eclipse Platform. Но я думаю, что сейчас пока не стоит
    > паниковать из-за Java 9, первое что могу сказать, - размер загружаемого
    > JDK с может увеличиться со 190 МБ до 200 с копейками
    > МегаБайт, ORACLE сама применяет в своих продуктах Java, думаю они там
    > не дураки, чтобы в один миг отказаться от того, что было
    > в Java 7, 8.

    Предварительную версию JDK 9 ещё не смотрели? Тут она: http://jdk.java.net/9/
    Там уже всё "модульно" и работает.

     
     
  • 4.123, Igor1986 (?), 19:29, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По поводу jdk9 я уже в курсе, более того, у меня после распаковки ZIP jdk вместо 256 с копейками Мегабайт "превратились" в 470 Мб. Про работающую "модульность" ты интересно сказал. Кстати, к своему же удивлению я увидел внутри очень похожее как в случае установки jdk8u121-i586.exe, а именно, похожие папки и файлы, которые после установки jdk8u121 или более поздней редакции jdk8u131, которая заходит в Program Files  (x86), это всё хорошо, но эту jdk9 просто так не "загнать" в Програм Файлз (x86), хоть и есть права Администратора, Eclipse IDE и NetBeans IDE всё равно "продолжат видеть" те же jdk8u121 или jdk8u131  (в зависимости от установленного JDK), но как вариант, можно попробовать "заставить" Eclipse IDE или NetBeans IDE начать видеть jdk9, и через этот девятый jdk "занырнуть" в модульность. Флаг нам, Javистам в руки и вперёд!!!! С Уважением, Игорь.
     
     
  • 5.129, yo (?), 04:05, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Столько радости по поводу Eclipse IDE я давно не видел. Переходите, Игорь, поскорее на IntelliJ IDEA, вообще в экстазе забъетесь ))). И новая JDK туда подключается пятью кликами мышки вне зависимости от того, где JDK лежит и у кого права администратора. (Справедливости ради, и в Eclipse и в NetBeans, думаю тоже легко подключить JDK откуда угодно, но я с ними давно уже не работал)
     
  • 2.91, Вареник (?), 09:50, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По хорошему надо было объединить OSGI и JDK, а не строить модульностью отдельно.

    У них была светлая идея сделать модули - deb пакеты (в формате deb), не понятно зачем это Java. Теперь вообще финт ушами, два года делать, сделать и решить не релизить.

     
     
  • 3.125, Igor1986 (?), 21:57, 12/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > По хорошему надо было объединить OSGI и JDK, а не строить модульностью
    > отдельно.
    > У них была светлая идея сделать модули - deb пакеты (в формате
    > deb), не понятно зачем это Java. Теперь вообще финт ушами, два
    > года делать, сделать и решить не релизить.

    deb пакеты - да, это странно, НО... для Линукс есть rpm пакет, но дело в том, что этот рпм как и установочный файл для Windows, - jdk8u121-windows-i586.exe служит для процесса установки в ОС (Операционной системе). Следует обратить внимание, что пакеты в Java не одно и то же что rpm, Java packages служат для запаковки Java классов и установления пространства имён и видимости классов.

     

  • 1.90, Вареник (?), 09:47, 11/05/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отменить модульность за месяц до релиза? Они охренели...
     
     
  • 2.98, Igor1986 (?), 10:23, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Отменить модульность за месяц до релиза? Они охренели...

    Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж сам думал что начну знакомиться с вкусностями Java 9, дабы понимать, что делать дальше, а тут получается опять "сдвиг" по графику аж на конец июля 2017(и это при условии, что JSR 376 таки одобрят), я пока применяю jkd8u121, - эта версия обновления очень даже чудненько работает.

    Мне не менее важно будет пронаблюдать за тем, что Eclipse Foundation будет предпринимать в связи с такими неизбежными Java 9 "улучшениями".


     
     
  • 3.101, Вареник (?), 10:29, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Eclipse Foundation

    За 15 лет работя с явой так и не понял этого IDE. NetBeans нормально, IDEA нормально, а Eclipse... не понимаю этого интерфейса, по мне - все неудобно сделано.

     
     
  • 4.106, Igor1986 (?), 10:43, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> Eclipse Foundation
    > За 15 лет работя с явой так и не понял этого IDE.
    > NetBeans нормально, IDEA нормально, а Eclipse... не понимаю этого интерфейса, по
    > мне - все неудобно сделано.

    Начнём с того, хоть по Eclipse и SWT/JFace (это графическая библиотека для Eclipse) и были выпущены книжные издания, рассказывающие, что и с чем едят SWT/JFace GUI, НО..., если ты заметил, что Java по внешнему виду и поведению (L&F Metal UI, я привык говорить Java Swing) давала возможность получить одинаковый вид что на Виндоус что на Линуксах, а вот в случае с Eclipse IDE идёт обращение к нижележащей ОС, хотя в NetBeans тоже можно было бы добиться вызова через JNI (Java Native Interface) нативных функций к самой ОС, что должно давать более быстрые результаты.  


     
     
  • 5.130, yo (?), 04:15, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вам похоже шашечки, а не ехать... Но хотя бы не обманывайте себя - одинаково эклипс выглядит и на винде и в линуксах и в макоси. Так что смысла от того, куда идет какое обращение не много. Быстрее ИДЕИ он если и работает, то не из-за обращения к ОС напрямую, а из-за отсутствия большого количества вспомогательных индексов которые ИДЕЕ позволяют ускорять разработчика.


     
  • 4.131, iZEN (ok), 17:48, 14/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>> Eclipse Foundation
    > За 15 лет работя с явой так и не понял этого IDE.

    Сколько ни пробовал разных версий IDEA, но не понял логику контекстных меню в этой IDE. Похоже на то, что об уместности и перечислении пунктов команд меню, возникающего по клику над местоположением курсора мыши, никто не думал. Кроме этого, IDEA часто виснет после нескольких запусков простых проектов - приходится убивать процесс самой IDE и запускать снова.

     
  • 3.103, Вареник (?), 10:32, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж

    Да, учитывая что они задержали релиз на год, ради модульности...

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

     
     
  • 4.108, Igor1986 (?), 11:02, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Такая непоследовательность может вызвать только недоумения.
    > Но если предложенная модульность не дружит с OSGI - то лучше ее
    > выкинуть, в этом они поступили мудро. Но не понятно почему так
    > запоздало.

    Для меня их запоздалость уже не удивление!!!Но всё же ждём вестей, как говорится!!!

     
  • 3.116, iZEN (ok), 20:45, 11/05/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Отменить модульность за месяц до релиза? Они охренели...
    > Ты обрати внимание, выпуск Java 9 в который раз "переносится", я уж
    > сам думал что начну знакомиться с вкусностями Java 9, дабы понимать,
    > что делать дальше,

    Пожалуйста, пройдите сюда и попробуйте уже: http://jdk.java.net/9/

    > а тут получается опять "сдвиг" по графику аж
    > на конец июля 2017(и это при условии, что JSR 376 таки
    > одобрят), я пока применяю jkd8u121, - эта версия обновления очень даже
    > чудненько работает.

    Странное желание "прислониться" к новой версии JDK, оставаясь на необновлённой предыдущей версии. Сейчас в моде jdk8u131. Даже на FreeBSD:
    % java -version
    openjdk version "1.8.0_131"
    OpenJDK Runtime Environment (build 1.8.0_131-b11)
    OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

    > Мне не менее важно будет пронаблюдать за тем, что Eclipse Foundation будет
    > предпринимать в связи с такими неизбежными Java 9 "улучшениями".

    OSGi Eclipse и модульность новой Java 9 никак не конфликтуют. А бажность эклипсовского фреймворка, когда внезапно после обновления среды оказывается, что модули почему-то не той системы/версии не работают в ней - известная проблема.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру