Pull to refresh

Comments 14

Вот так Java медленно превращается... медленно превращается... в PHP =)

Уже было и прошло. JSP это и есть PHP

Нишу JSP нынче осваивает шарп с блейзором, а я про другое немного.

PHP по принципу своей работы вначале из сырцов компилится в опкод/байткод, потом запускается и по-дороге ещё в машинный собирается где можно (ака JIT). И всё это командой php path/to/Source.php.

Вот на это я и намекнул, что вместо javac + java получаем один java, который делает всё это вместе как пых.

Так и JSP компилится в байткод, который тоже JIT. Там просто 2 шага
1. JSP to Java
2. Java to bytecode

Не совсем. Ещё третий шаг - рантайм. Когда сам байткод выполняется на JVM.

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

Я до сих пор помню, как был шокирован и потрясен, когда впервые увидел Eclipse и POM. И, между прочим, дело во мне! 

А в чем, собственно, проблема? Т.е. вы захотели съесть стейк, а, оказывается, его нужно готовить! Как-то раньше ни кого не шокировал ни компилятор, ни линковщик, ни отдельный отладчик. Я, как раз, за прогресс. Сам не люблю ни Eclipse ни Maven.

Но когда новичок, даже, не готов прикладывать усилия, то и результат будет такой же. Как раз посмотрите на все языки с низким порогом вхождения и что видим? Синоним бардака и антипаттернов - и так сойдет! А так хоть какой-то естественный отбор :)

Тогда легкий редактор и несколько двумерных файлов как раз могут вам подойти, по крайней мере, на некоторое время.

Я должен увидеть эти файлы.

Не иначе, как это обычный 3-мерный файл, по которому ударили оружием снижения размерности.

Зачем Николай Парлог завлекает читателей кликбейтным заголовком? Оказывается, он спешит нам сообщить, что теперь Java (наконец) научилась понимать, что такое корневая директория.

И для чего было бы полезным такое умение? Вот что пишут в JEP:

This will make the transition from small programs to larger ones more
gradual, enabling developers to choose whether and when to go to the
trouble of configuring a build tool.

Нужно ли понимать данный пассаж как существовавшую ранее необходимость "to go to the
trouble of configuring a build tool" всего лишь после добавления второго Java-файла? И если нет, то как же по другому можно понять смысл сказанного?

Для справки: все сегодня пишут в IDE. Те, кто там не пишет - не занимаются серьёзными проектами. IDE выполняет компиляцию и запускает программы уже давно, примерно с версии Java 1.0, хотя некоторые утверждают, что замечали подобное поведение и раньше. Поэтому непонятно, при чём же здесь build tool?

Давайте скажем проще - Java потихоньку движется в сторону скриптовых языков. И с учётом этого направления сразу становится ясным предназначение очередного JEP. А вот заманушный заголовок Николая Парлог лишь вводит нас в заблуждение.

Хотя кто его знает, может разработчики Java и вправду не используют IDE? Тогда текст Николая тоже становится понятным, но уже несколько по другому.

Ну вот у меня сейчас получается, что удобнее делать не маленькие проекты под маленькие эксперименты с языком, а один большой.
Потому что даже маленький проект - это не просто файлик с кодом, а всякие build.gradle, gradle-wrapper.jar, папка для временных файлов системы сборки и т.п., хотя по-сути всё что мне нужно - это запустить немножко кода.

>... запустить немножко кода.

jshell

Какой-то словесный мусор. Такое впечатление что писал бот, а переводил Google Translate.

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

Так, скажите просто - когда python/js/нужное_вписать скрипты можно будет заменить джавой?

Sign up to leave a comment.