Программист
0,2
рейтинг
23 марта 2014 в 00:04

Разработка → JPHP — Новый движок php для Java VM + JIT

Представляю вам свой open-source проект — JPHP. Это альтернативная реализация PHP для JavaVM с поддержкой JIT. Я начал проект в одиночку в октябре 2013 года и за 4 месяца реализовал компилятор php в байткод JVM. Язык поддерживается на уровне PHP 5.3, частично поддерживаются возможности PHP 5.4 и 5.5. По своей идеологии проект напоминает JRuby и Jython.

Я подготовил небольшую презентацию, которая расскажет о проекте и не отнимет у вас много времени:



Есть желание рассказать о проекте как можно больше, но боюсь все в одну статью не уместить. Надеюсь получилось не слишком сумбурно.


  • Лицензия: Apache License 2.0
  • Сайт проекта: j-php.net
  • Исходники проекта: https://github.com/jphp-compiler/jphp
  • Совместимость: JavaVM 1.6+ (Linux, Windows, MacOS, работает везде где есть Java).


Цель проекта


JPHP это не замена для Zend PHP или Facebook HHVM, потому что в планах не было реализации всех runtime библиотек zend php, таких как CURL, PRCE, PDO и т.п. Основные причины, побудившие начать проект были следующие:

  • Это был эксперимент
  • Использование java библиотек в PHP
  • Увеличить производительность за счет JIT + JVM
  • Заменить несогласованный и уродливый рантайм Zend PHP на что-то более приличное
  • Позволить писать на PHP не только под Web
  • Реализовать поддержку юникода и многопоточности


Технические детали


Весь язык написан с нуля на Java с применением библиотеки ASM для генерации байткода, её используют все популярные jvm языки, например Groovy. В качестве системы сборки был выбран Gradle.

К моему удивлению, стек технологий Java предоставляет очень удобные условия для написания jvm языка. Не нужно писать свою VM с JIT, сборщик мусора и система классов уже реализованы, не болит голова о кроссплатформенности, а сам байткод jvm очень легок в понимании. Однако было много и подводных камней, больше всего из-за магии самого языка php.

JIT позволил увеличить производительность в 1-10 раз, в зависимости от тестов, в среднем в 1.5-3 раза на реальном коде. Я также реализовал оптимизатор, который помогает сделать код еще быстрее.

Совместимость с PHP?


Стоит различать язык и библиотеки к нему, поэтому совместимость на уровне языков и библиотек это разные вещи. Уже в начале разработки я понял, что написать с должной совместимостью все библиотеки PHP невозможно одному человеку. Я решил сконцентрироваться лишь на языке, хотя и реализовал базовые вещи, такие как spl autoloading, Reflection, ob_* функции, <? ... ?> и многое другое.

JPHP проходит около 300+ юнит-тестов от оригинального Zend PHP, среди которых тестирование ООП, функций, операторов и т.п. Есть также и свои тесты. Это помогает быть уверенным, что язык работает должным образом. Далее я перечислю список фич, которые поддерживаются:

  • Язык на уровне PHP 5.3 (за исключением goto)
  • Typehinting для callable (5.4)
  • Короткий синтаксис для массивов (5.4)
  • Class::{expr}(), (new Foo)->bar() (5.4)
  • try… finally (5.5)
  • Array and string literal dereferencing (5.5)
  • Function array dereferencing foo()[0] (5.4)
  • Системная константа class для получения имени класса (5.5)


На подходе реализация трейтов из php 5.4.

JIT и производительность


Как вы думаете, какой код может влиять на производительность? Если вы хорошо знакомы с Facebook HHVM, то думаю вы знаете какой. Основная проблема производительности PHP это глобальное пространство для переменных, магия переменных, просто магия, когда можно обращаться к переменной по имени во время выполнения. По этой причине JPHP по-разному может компилировать один и тот же код. Там, где нет магии с переменными, компилятор преобразует переменные в индексы и во время выполнения сразу обратится к ним по индексу. Давайте я приведу несколько примеров:

$var = 'foobar';
$x = 'var';
${$x} = 'chanched'; // магия переменных

$global_var = 100500;
include 'file.php'; // магия переменных, в include нужно передать global scope с именами

function foobar() {
   $x = 100500;
   $var = get_defined_vars(); // опять магия переменных
}


Поэтому, когда предполагается обращение к переменным по имени во время выполнения, JPHP сохраняет таблицу имен переменных, а когда нет — не сохраняет и обращается к переменным сразу по индексам.

Магия переменных примерно в 2 раза замедляет ваш код в JPHP. В Zend PHP код одинаково работает при любых условиях.

Оптимизатор


Оптимизатор JPHP умеет довольно много, вот небольшой списочек его возможностей.

1. Константные выражения
$x = (20 + 30) . 'foobar';  // посчитается во время компиляции 1 раз


2. Статические константы
Есть такие константы, о которых JPHP знает на момент компиляции, а есть динамические константы, объявленные через define. Статические это системные константы __FILE__, __DIR__, __CLASS__, константы java расширений, константы, которые объявлены в рамках одного файла через const. Все их можно заменить во время компиляции:
include __DIR__ . '/core.php'; // конкатенация произойдет во время компиляции


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

for ($i = 0; $i < 100500; $i++){
    $x = cos(1) + 3; // посчитается 1 раз во время компиляции, а не 100500
}

В данном примере функция cos() системная и immutable, а параметр переданный функции, является константой, поэтому результат cos(1) никогда не изменится.

К immutable относятся и функции/методы, объявленные программистом, которые не имеют параметров и возвращают константное выражение. Вызов такой функции в JPHP сравним по скорости с обращением к константе, например:

function getVersion(){
    return '1.0';
}

$x = getVersion(); // быстрый вызов

define('VERSION', '1.0');
$x = VERSION; // стоимость вызова константы = стоимости вызова предыдущей функции


4. Невыполнимые условия
Если в if или elseif у вас константное выражение, которое всего ложно, компилятор отбросит лишнее условие совсем. Пока поддерживаются лишь if, else и elseif. Например, это бывает очень полезным:

if (TRACE_ENABLED){ // если TRACE_ENABLED = false, то компилятор сможет удалить мертвый код
     log("Log text...");
}


Кэширование классов, функций, байткода?


Модель работы JPHP позволяет хранить скомпилированный код в памяти, т.е. классы и функции. Один раз скомпилированный и загруженный класс будет использован многократно. В перспективе это позволит писать http сервера, фреймворки по производительности не уступающие Phalcon на самом PHP. Данные легко хранить между запросами, а http сервер можно написать на самом php, о чем я расскажу ниже.

В JPHP есть специальный класс Environment, который позволяет создавать изолированные окружения для выполнения скриптов, это чем-то похоже на sandbox из расширения runkit. У каждого такого окружения свой набор классов, функций и глобальных переменных.

  • Environment — изолированное окружение для выполнения скриптов
  • Подобен sandbox из runkit
  • Нужен для гибкой реализации многопоточности
  • Позволяет организовать HOT reload схему работы
  • Окружения могут взаимодействовать друг с другом


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

Как попробовать? Собрать тестовый проект?


Для этого вам нужно установить Java (1.6+) и систему сборки Gradle (1.4+). Скачать исходники из git репозитория. JetBrains IDEA позволяет импортировать проект из build.gradle. На данном этапе есть тестовый проект в папке jphp-example-project. Этот проект собирается в выполняемый jar файл, внутри которого находятся исходники php. При запуске jar выполняется bootstrap.php файл. Собрать jar можно с помощью команды:

gradle jar

Или сразу запустить через:

gradle exampleStart


Проект собирается в папке build/libs/ в jar файл.

GUI? Программы?


Я также написал расширение-обертку для Swing (библиотека Java для GUI). Она позволит вам создавать кроссплатформенные GUI программы. Для тех кто знаком со Swing, хочу обнадежить — я довольно сильно упростил апи и систему layouts. Небольшое окошко на GUI:

    use php\lang\System;
    use php\swing\SwingUtilities;
    use php\swing\UIForm;
    use php\swing\UIDialog;
    use php\swing\UIButton;

    SwingUtilities::invokeLater(function(){
        $form = new UIForm();
        $form->size = [500, 500];
        $form->moveToCenter();
        $form->visible = true;

        $p = new UIButton();
        $p->size = [300, 40];
        $p->align = 'top';
        $p->h = 30;
        $p->text = 'Кнопка';
        $p->on('click', function(){
              UIDialog::message('Примет', 'Заголовок');
        });
        $form->add($p);

        $form->on('windowClosing', function(){
            System::halt(0);
        });
    });


Многопоточный HTTP сервер?


На JPHP можно вполне написать многопоточный http сервер. Для этого я импортировал классы Socket и ServerSokect, а также классы потоков Thread.

    use php\concurrent\ExecutorService;
    use php\io\IOException;
    use php\lang\Environment;
    use php\net\ServerSocket;

    $server = new ServerSocket();
    $server->bind('localhost', 8080);
    $service = ExecutorService::newFixedThreadPool(5); // create a thread pool

    echo "Start HTTP Server on http://localhost:8080/ ...\n";

    while (true) {
        $socket = $server->accept();
        echo "Connect client ... \n";

        $service->execute(function() use ($socket) { // processing a http request in a thread
            ob_implicit_flush(true);

            $out = $socket->getOutput();
            try {
                $out->write("HTTP/1.1 200 OK\r\n");
                $out->write("Content-Type: text/html\r\n");
                $out->write("Connection: close\r\n\r\n");

                $out->write("Hello world!");
                $out->flush();
            } catch (IOException $e) {
                echo "Error: " . $e->getMessage(), "\n";
            } finally { // JPHP supports `finally` as in PHP 5.5
                $socket->shutdownOutput();
            }

        }, new Environment());
    }


Такой сервер довольно быстро отдает контент, я тестировал через утилиту ab и результаты впечатляют. На моей машине (Java 7, i3, Windows 7) такой сервер в состоянии обрабатывать 4000-5000 запросов в секунду (ab -n50000 -c100 localhost) и не падать.

Что дальше?


Я планирую развивать сам JPHP, довести его до релиза, реализовать все языковые возможности до PHP 5.5. Возможно попробую реализовать совместимость с Android (по примеру Roboto для JRuby). Реализую нормальные расширения, основанные на namespaces и ООП, частично я кое что уже реализовал — потоки, сокеты, gui, json.

Остальное смотрите в презентации. Благодарю за внимание.
Дмитрий Зайцев @dim_s
карма
95,0
рейтинг 0,2
Программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (108)

  • +6
    Занятно! А во время реализации возникала проблема с тем что сам по себе PHP — язык не строгой типизации, а Java — строгой или на уровне байт-кода никакой разницы нет?
    Вы не могли бы отдельной заметкой рассказать процесс создания JPHP? Я думаю многим было бы интересно.
    • +2
      С типизацией проблем не было вообще никаких. Проблема в другой магии, например вызов динамичных методов статичным способом, система классов java не позволяет делать такое. Я хотел написать о процессе создания, но понял что все это не влезет в одну статью. Напишу потом отдельную статью.
      • 0
        вызов динамичных методов статичным способом

        invokedynamic? Оно позволяет во время выполнения определять, какой код будет вызван, с произвольным механизмом разрешения целевого метода.
        • +2
          Да, но он не поддерживается в Java 6, а она еще очень распространена.
          • +33
            Когда создаёте столь специфичное решение, вы в праве требовать специфичного окружения и не париться.
          • +3
            Не хочу обидеть, но наболело. В частности, именно из-за такой логики древнее г-но типа Java 6 до сих пор и используется. Шестой джаве уже шесть лет, седьмой — почти четыре года, только что восьмая вышла. Если цепляться за эти древности, то на свежие версии никогда перехода не будет. А это очень печально :(

            Посмотрите на Ceylon — авторы языка явно требуют Java 7. А этот язык гораздо ближе к джаве, чем ваш. Полностью поддерживаю igordata.
            • +3
              PHP 5.3 вышел в 2009 году, ему тоже 6 лет, однако многие его еще поддерживают. JRuby и Jython поддерживают Java 6. С моей стороны переход на Java 7 ничего особенного кроме invokedynamic не дает. Скажу честно, без него прекрасно можно обходиться, но это технические детали, если вкратце, то порой вызов метода рефлексией бывает быстрее, чем через invokedynamic, только в Java 8 они это поправили.
              • +3
                Всеми известная и любимая Scala поддерживает еще JDK 1.6
                • 0
                  Кстати, интересно, как на ней на уровне JVM реализованы «функции как первоклассные объекты» — через синглетоны типа как анонимные классы в Java?
                  • 0
                    Да так и есть, если я не ошибаюсь. По сути анонимных классов в байткоде JVM не существует, они превращаются в именованные классы и название у них = «имя класса в котором находится анонимный класс» + "$" + «index + 1».
                    • 0
                      На каждый чих (а в идеале можно все циклы заменить ленивыми списками ;-) ) по классу в PermGenSpace. Весёленько…
              • +3
                Вы выпускаете рантайм, которые если и будет использоваться (уж извините за пессимизм, но он уж очень специфичен, и в сравнении с HHVM пользоваться им будут не так часто), то поставить нужную версию JDK/Java не составит проблем. То есть вы вправе делать все даже уже и под 8-ую версию.
                • 0
                  Поддержу. Требования к обратной совместимости отсутствуют.
                • +5
                  Если я хочу в дальнейшем реализовать поддержку/порт под Android, то мне нужна поддержка Java 6, т.к. Google только недавно реализовал поддержку Java 7.
              • 0
                У меня сейчас не получилось найти ссылку на запись выступления Алексея Шипилева, где он рассказывает __какие__ баги были пофиксены в jdk седьмой версии (куча багов с concurrency, например). При этом фиксы не были включены в шестую jdk.
                Поэтому, юзайте jdk6 на свой страх и риск. :)
                • +2
                  Это же не значит, раз я поддерживаю jdk6, то использую ее. Запускайте jphp хоть на jdk7, хоть на jdk8, эти проблемы будут решены, о которых вы пишите. Но для андроида нужен jdk6. Кстати на 1.7 jphp работает быстрее, а на 1.8 еще более быстрее.
          • +2
            Пожалуйста, выбросьте поддержку Java 6.
  • +2
    JPHP компилирует PHP-код в сборку, совместимую с другими java-приложениями, или же выполняет код в рантайме? Есть ли возможность кросс-взаимодействия, например импортировать в php-скрипт некий внешний java-тип?
    • +4
      Он компилирует в байткод JVM, который можно сохранить в файл и загрузить его заново. Однако, чтобы вызвать код php из java, например метод класса, нужно использовать апи движка, уж сильно большие различия в ооп, да и еще динамическая типизация не позволяет сделать это просто. Можно писать расширения на Java.
      • 0
        Класс! Кстати, вы не смотрели на реализацию компилятора PHP под .NET? Устройство виртуальных машин довольно схожее, возможно удастся что-то почерпнуть. Правда, я давно не слежу за проектом — не знаю, насколько он совместим с последними возможностями языка.
        • +2
          Нет только в общих чертах. Они заявляют о поддержке php5.4+. В основном я смотрел реализацию quercus.caucho.com/, но это транслятор в java код, а не компилятор в jvm байткод.

          Думаю .NET байткод еще более продвинутый.
  • +1
    Такой странный вопрос: почему JVM, а не LLVM? Рассматривался ли LLVM вообще?
    • +4
      Потому что я программирую на Java в основном, опыта работы с С++ у меня вообще нет. Я даже не знаю, есть ли в LLVM свой сборщик мусора? Были предложения написать php2js, но это показалось мне более сложным и бесполезным делом.
      • –6
        LLVM это вообще не виртуальная машина, LLVM — это не аббревиатура.
        • +2
          Если верить вики, то это как раз таки аббревиатура: Low Level Virtual Machine (LLVM)
      • +1
        Там есть кое-какая поддержка для GC, но писать его надо самостоятельно. И естественно там нету свинга и вообще ничего, зато есть JIT компиляция в native code.
        По крайней мере цели «увеличение производительности» и «писать не только под Web» это бы выполнило, но не было бы доступа к мощи библиотек Java. Так что неизвестно еще что лучше.
    • +5
      Если у автора была цель — интероперабельность с Java-библиотеками, Swing, Android, то при чем тут LLVM?
    • +1
      такого вроде как много: github.com/preillyme/llvm или gitorious.org/php-llvm,
      • +2
        И все мертво. Такие проекты обычно возникают как попытки, но в силу того что один два разработчика не могут выпустить рантайм, который можно использовать в продакшене, толку от этого мало.

        Есть шанс что к php6 перепишут рантайм с использованием JIT, оптимизируют сборщик мусора и еще много чего интересного, но… если нужна производительность, то проще взять либо HHVM+Hack либо вообще штуки типа golang…
  • +1
    Здорово. Еще один язык для Vert.X
  • –1
    То есть по своей сути Ваша разработка это… как же выразиться правильно… это возможность писать на Java'e (иметь доступ к набору привычных классов), используя синтаксис PHP? Или все же возможность программировать на PHP с привычными для PHP средствами, но крутиться это все будет на JVM? Второй случай больше похож на JRuby, но по примерам больше похоже на первый вариант…
    • +4
      Что-то среднее. Я написал, что не в силах реализовать рантайм библиотеки, хотя в самом начале хотел. В JPHP и правда, через рефлексию Java можно работать с библиотеками написанными на Java (кстати и на Scala, jvm языки возможно).
  • +5
    Брутально!
  • 0
    А в чем проблема с goto?
    • +2
      Это не религиозное убеждение, просто лень, будущем реализую, а break, continue поддерживают многоуровневый выход.
      • 0
        Понимаю)) Удачи. Смотрю на реализацию php методов, и мне чтото это напоминает) Спасибо за проект, будет время — разберу на кирпичики)
  • +16
    Честно говоря, сделать такое за 4 месяца в свободное от работы время — это прямо подвиг! Сколько примерно времени в день вы выделяли?
    • +2
      очень любопытно посмотреть на простенькие бенчмарки (что сильнее ускоряется, что нет) и потребление памяти.

      p.s. промазал веткой.
      • +3
        Будет отдельная статья про бенчмарки. По потреблению памяти примерно также как в PHP. zval структура в zend движке примерно столько же занимает в памяти сколько и объекты Memory (через которые jphp сохраняет значения).
    • +5
      У меня огромный опыт в написании различных компиляторов, трансляторов, парсеров, писал несколько раз свою VM, прочитал много книжек о построении компиляторов. Начал я этим увлекаться 4 года назад. Этот проект весь мой опыт, который я накопил за такое время. Я прекрасно знал как его надо написать.

      В 2011 году у меня была первая попытка написать движок php — http://www.freepascal.ru/forum/viewforum.php?f=4 (исходники есть в моем репозитарии). До этого писал скриптовые языки, писал препроцессоры для css.
      • +3
        Не правильную ссылку дал: www.freepascal.ru/forum/viewforum.php?f=42
        • 0
          О, я помню его анонс на винграде.
      • –1
        Все равно кажется невероятно. По заголовку показалось, что какая-нибудь соцсеть снова шаманит, ускоряется. «Я… в одиночку… за 4 месяца» раза 3 перечитал. Невероятно :)
        • +2
          Когда-то я уже писал, что у известных JVM языков всего 1-3 мейнтейнера, а не целая команда разработчиков. Вы можете поглядеть статистику коммитов у Groovy, JRuby или Scala.
      • +3
        если не секрет, Вы этим занимаетесь по работе или это хобби?
        Жить ведь на что то надо, семью кормить а такие проекты требуют уйму времени. Всегда было интересно как некоторым удаётся совместить безумно интересное занятие и не умереть при этом с голоду. Поделитесь как Вам это удаётся.
        • +3
          На работе я занимаюсь разработкой backend серверов на Java для мобильных приложений, пишу различные REST api и т.п. А этот проект естественно хобби. Но разрабатывая такой перспективный проект, я работаю на свое светлое будущее, поэтому оно стоило того, чтобы месяц два вести очень активную разработку. Тем более за последние полгода у меня появилось больше свободного времени.

          И детьми и семьей еще не успел обзавестись, молодой еще)
          • 0
            Простите, а в чем «перспективность» проекта? Производительность рантайма будет относительно слабенькой, так как не будет поддержки всех фич Zend engine, большая часть либ и фреймворков прост не заведутся, и никто собственно что-то серьезное под web делать с ним не будут. Использование java библиотек… тоже сомнительный плюс… Возможность писать расширения на PHP — для этого было бы логичнее воспользоваться подходами, используемыми в PyPy (ограниченное подмножество языка с добавлением статической типизации), собственно как это сделано в Hack и Зефире. Тогда можно будет получить худо бедно приличную производительность этих самых расширений. Возможность писать GUI приложения — тоже сомнительно.

            Время покажет конечно, но с учетом того что вы занимаетесь проектом в свободное время и в одиночку, без наличия какого-либо сообщества, проекту такого плана просто не выжить, или же он будет намного слабее конкурентов.
            • +7
              А фреймворки и не нужны, я последую примеру node.js, когда все завертелось буквально с нуля. Сообщество появляется уже, как только я впервые опубликовал информацию о проекте. Со временем появятся и фреймворки.

              Использование Java библиотек это не сомнительный плюс, это огромный плюс. Т.к. JVM инфраструктура развита очень сильно, огромное количество стабильно развивающихся библиотек, которые пишутся на Java, Scala, Groovy и других jvm языках. PHP такое и не снилось.
  • +2
    >Такой сервер довольно быстро отдает контент, я тестировал через утилиту ab и результаты впечатляют.

    у меня вопрос: если к вам придёт 16к клиентов с gprs и будут мееедленно, по байту в минуту читать ответ, что станет с вашим сервером?
    глядя на $service = ExecutorService::newFixedThreadPool(5); возникает стойкое ощущение, что на первых пяти клиентах всё и закончится.
    • +2
      Это просто пример, есть разные политики для пула потоков. Если нужен асинхронный сервер, то можно попробовать интегрировать vert,x.
      • +2
        Еще более простой вариант — неблокирующее IO. Это полностью решит проблему и 5 потоками.
        • –1
          >Еще более простой вариант — неблокирующее IO. Это полностью решит проблему и 5 потоками.

          до того момента, пока вам не надо читать с диска.
          • +1
            При отдачи контента с диска читать не нужно, JPHP может кешировать загруженные классы и не обращаться за исходниками через файловую систему. Остальное на совести программиста. Эту проблему должен решать уже программист.
            • –4
              я к тому, что неблокирующего чтения с диска не бывает.
              • +1
                Процессор опрашивает контроллер диска в цикле для каждого байта?
                • 0
                  причем тут контроллер диска? это может быть какой-нибудь iscsi/fcoe/aoe, ситуация не меняется.
                  то, что вы открыли файл с O_NONBLOCK ровным счётом ничего не решает и если данных нет в vfs cache, ваш процесс/тред «залипнет».

              • 0
                граждане минусующие, может поясните свою позицию?
      • 0
        >Это просто пример, есть разные политики для пула потоков.

        ну ок, 64/128/256k клиентов. вы же тредов не напасетесь.

        >Если нужен асинхронный сервер, то можно попробовать интегрировать vert.x

        вокруг этой штуки слишком много хайпа. ну и «A verticle instance is strictly single threaded.» доставляет. код внутри вертикля должен исполнятся очень быстро и никого не ждать(например, бд).
        • +3
          Если вам нужно так много клиентов, то используйте Erlang например.
          • 0
            почему не scala/java + netty?
            • +2
              Netty предоставляет только асинхронный IO.
              • 0
                а зачем какой-то еще? и не путаете ли вы асинхронный и неблокирующий i/o?

                ваш труд достоен уважения и всяческих похвал, но целевая аудитория непонятна.
                писать гуи на пхп — ок, допустим.

                писать веб-сервера? — зачем? в cpu они никогда не упираются и основная проблема там — дисковый i/o.
                а горячий кусок кода проще реализовать как c-extension или внешний процесс.
                • +3
                  Не проще реализовать из-за того что с-extension нужно писать на сложном си или с++. Архитектура работы JPHP позволит реализовать htttp сервер и фреймворк по типу Phalcon на самом php, без всяких расширений.

                  • –1
                    >Не проще реализовать из-за того что с-extension нужно писать на сложном си или с++.

                    не надо переписывать всё. переписать надо лишь небольшой кусок. и задача особенно упрощается наличием трансляторов в C/C++

                    >Архитектура работы JPHP позволит реализовать htttp сервер и фреймворк по типу Phalcon на самом php, без всяких расширений.

                    а вы можете показать пример с отдачей файла, лежащего на диске? для тех же 16к коннектов?
                    • +2
                      Я еще не занимался этими вопросами и пока это лишь тестовые примеры. Все таки такого добиться на Zend PHP будет намного сложнее.
                      • 0
                        • +2
                          Все что умеет Java сможет и JPHP, поэтому я за такие технические детали не переживаю. Расширение по ссылке имеет версию 0.0.1dev.
  • 0
    Есть такой проект, как resin + php, можно чуть подробнее — отличия/достоинства? Ну так, в двух словах.
    Еще хочется больше бенчей, не только совсем синтетических.
    • +6
      Как я писал в презентации — это транслятор в Java код. Поэтому для его работы требуется весь JDK и компилятор Java (javac). JPHP сам является компилятором и конечный результат это байткод JVM. Querqus делает так PHP -> Java -> javac -> байткод, а jphp: PHP -> байткод. Поэтому достаточно установленного JRE. Возможно лицензия GPL (querqus) не всем понравится из-за невозможности использовать проект в закрытых системах. К тому же байткод получается более оптимизированным, чем сгенерированный код Java.

      Авторы этого проекта заявляют у себя на сайте, что их система работает с такой же скорость как PHP + кешер. Они ориентируются только на веб и на полную обратную совместимость и с библиотеками тоже.
  • 0
    Возможно ли использовать апи без use, т.е. \name\class?

    Может и глупый вопрос, но у вас это больше похоже на import из java
    • +5
      Это стандарт языка php. В PHP группе были когда-то обсуждения, чтобы перевести все core функции и классы в отдельный namespace — php. IDE позволяет не заботится об этом. В любом современном проекте, фреймворке, библиотеке используются namespaces и вам все равно придется использовать их.
  • 0
    Я правильно понимаю что JPHP можно использовать в вебе (сайтах) и обращатся к JAVA функциями?
    • 0
      Тоже интересует этот вопрос, но я так понял, для разработки под web этот проект не годится, верно?
      • +2
        Проект разноплановый, будут библиотеки для более удобного создания http сервера, как например в node.js, соответственно и под веб можно будет писать.
        • 0
          А отладка кода возможна?
          • +1
            Будет возможно, вместе с JVM поставляется штатный отладчик, который легко можно будет интегрировать (я уже думал об этом). Поэтому это вопрос времени.
            • 0
              А какие выгоды привносит эта технология? Почему нельзя взять средство которое уже создано для «этого» и научится ему? Становится ли решение задачь, которые изначально стояли перед PHP, более простым/эффективным/добавить_свое?
  • +5
    Вы вероятно, тот самый избраный, о котором говорили пророки, вы убийца ПХП!!!
    У этой разработки огромный потенциал.
  • 0
    Насколько я понимаю, функции не могут быть immutable, однако они могут быть чистыми.
    • +2
      * не изменяют внешнее окружение, это функции для работы со строками, с числами и то что я описывал в статье.
      • 0
        Поиск в гугле «PHP immutable function» ничего не дал. Интересно, откуда у вас этот термин? Думаю, название "константные" подошло бы больше… Хотя могу ошибаться, м.б. это уже устоявшийся термин…
        • 0
          Ну этот термин вроде пришел из функциональных языков. Функция, которая ни на что не влияет, самодостаточна, при одном наборе переданных ей значений возвращает всегда один и тот же результат.
          • 0
            А, точно, без «PHP» и в кавычках выдаёт почти исключительно доки по PostgreSQL. Если исключить PostgreSQL — искать «"immutable function" -postgresql», то из результатов с первой страницы особенно хорошо разъяснено, например, здесь.
          • 0
            "Чистая функция", как говорит нам Википедия, — это практически то же самое… Но, в общем, благодарю вас за знакомство с новым термином, оспаривать его применимость в данном контексте не намерен;-).
    • 0
      Как я понял, имеются в виду два подвида чистых — функции, возвращающие константу, и чистые функции с константными параметрами в местах вызова.
  • 0
    А есть мысли расширить синтаксис PHP и ввести, например, статическую типизацию? Может это дать существенный выигрыш в процессоре/памяти без сильного изменения движка? Или, как вариант, автоматический вывод типов, там где это возможно.
    • +2
      Это риск и большой труд, для расширенного синтаксиса необходимо писать поддержку под различные IDE. Тем более пока есть пространство для других оптимизаций в рамках текущего синтаксиса.
      • 0
        В общем-то да, статически типизированный язык для полного раскрытия своих возможностей требует IDE. Что фактически умножает в разы усилия по его созданию…
  • 0
    Работа отличная, я даже не представляю, как такое чудо можно сотворить за 4 месяца!
    Но вот поддержка битовых операторов реализована не до конца:
    error_reporting( E_ALL & ~E_NOTICE );
    

    Вызывает parse error.
    • +2
      Пожалуйста пишите о таких ошибках в трекер (это ошибка анализатора). github.com/dim-s/jphp/issues
  • 0
    Есть подозрение, что расширения для PHP доступны в виде С-исходников, а также есть надежда, что должно быть нечто вроде компилятора С для JVM, которым эти исходники можно было бы (после небольшого настраиваемого автоматического преобразования) скомпилировать под него…

    Накрайняк — можно пойти по нативному пути и сделать «обёртки», позволяющие скомилировать эти исходники как часть нативных библиотек для JVM…
    • 0
      Обертки для вызова кода из си библиотек есть для JVM, но это создает зависимость от платформы и рушит всю идеологию Java. В общем если найдутся добровольцы и сделают такое в виде расширения (типа обратная совместимость с zend), то я не против.
      • 0
        А что на счет модуля для совместимости на уровне стандартной библиотеки оригинального php? В частности, те же filesystem функции, о которых я писал на гитхабе вам.
        • 0
          Это не первостепенная задача, как я написал, сам я реализовывать расширения zend не буду, нет желания, времени и возможностей. Легче реализовать альтернативный более качественный рантайм, согласованный (причем это будет намного быстрее). В крайнем случае для этого рантайма можно написать аналог на самом zend php, чтобы переход был более плавным.
  • 0
    Мы в одном проекте используем Quercus, решили попробовать заменить на jPHP. Как-то грустно без документации. Не получилось загрузить из Java переменные в Environment и выполнить скрипт. Скрипт выполняется, а данные передать «в скрипт» не можем. Есть ли такая возможность вообще? Можно свои переменные из Java в PHP передать?
    • 0
      Да это возможно, например через глобальные переменные, документации пока нет, но когда появится сайт постепенно появится и документация. Заменять quercus бесмысленно в том случае если вы хотите обратной совместимости с php на уровне расширений.

      • 0
        Расширения не используются, на PHP только шаблоны для страниц написаны, поэтому jPHP заинтересовал. Может попозже еще один заход сделаем и еще раз попробуем перейти.
        • 0
          Да пожалуйста не нужно его использовать на данном этапе в серьезных проектах, т.к. все в режиме активной разработки, что-то может быть не стабильным.

          А вообще есть такая вещь как ModuleEntity в jphp ядре, это грубо говоря подключенный php скрипт, у этого объекта есть метод include, есть вариант куда можно передать список переменных через параметр ArrayMemory — это массив пхп.
          • 0
            До ModuleEntity и Memory по==докопался, а вот то, что через Include можно передать данные — не сообразил. Вобщем ждем немного больше информации, каких-нибудь примеров. Из тестов набралось не достаточно информации.
            • 0
              В общем-то передавать информацию различными способами можно и через объект environment, или вызвать какую-нибудь функцию/метод.

              Стало интересно на счет использования пхп в качестве шаблонизатора в java проектах, интересно, каков был мотив и причины?
              • 0
                Своя платформа для онлайн магазинов с поддержкой шаблонов от одного из PHP'ных движков
        • +1
          Но спасибо за проявленный интерес к проекту =)
  • 0
    Крутая идея! Не знаю как реализация в проекте но идея будет двигать остальных создать или по крайней мере рискнуть создать что то подобное, соберите сообщество или попросите сделать это кого то из друзей или коллег! Если будете продолжать сами вы быстро загнетесь, проект до нового года не доживет без поддержки и постоянных релизов в виде фич и обновлений от сторонних разработчиков!
    Удачи в проекте, я буду следить за данным проектом, надеюсь прислушаетесь :)
    • 0
      Заодно присоединяйтесь к тестированию, отправке пулл-реквестов, написанию предложений! ;)
  • 0
    Можно ли использовать это для использования php кода из джава? Типа как груви
    • 0
      Можно, но пока проблема в том, что большая часть оригинальных PHP функций не реализована, ибо есть своя библиотека обернутая в ООП с более качественными реализациями. Потому дабы ваш код работал, надо будет его переписать именно под JPHP.

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