JSR 223 to enable interop with Java & scripting languages

Discussions

News: JSR 223 to enable interop with Java & scripting languages

  1. The new JSR 223 (Scripting Pages in Java Webapps) aims at defining a way for Java classes to be invoked from a page written in any scripting language. PHP will be used in the reference implementation, but the intent to support any scripting language. An interview with PHP co-designers Zend Technologies provides more insight into JSR 223.

    Read JSR Aims to Improve Java, Open Source Scripting Ties (oetrends), and the JCP JSR Page.

    Related article:
    Sun, Microsoft Seek to Embrace Dynamic Scripting.

    This JSR is pretty exciting. Imagine being on a project where you (the backend developer) can write a set of busines delegates that can be used by PHP guys.
  2. i think this is nothing but a good thing for both sides. i've been waiting for a long time for a robust and more appropriate marriage between these two technologies. when php4 rc's were released i was excited with the ability to hook in java classes and then disappointed with the limitations.

    this announcement allows php to scale and pull in enterprise resources off of java's backbone, and it allows java to have an extremely fast, mature, feature-rich native web interface (i am not saying jsp/servlets are not fast or mature). once this is released the only decision is to use php or jsp? let's just hope they will allow us to write php & jsp code inside the same pages, and have it interoperate, a lot of php functions are extremely useful, and quick to implement.

    enjoy
  3. Sounds really nice. My only concern so far is TCK (Test Compatibility Kit) licensing. It was my understanding that with the new JCP version, it was up to the submiters to decide on TCK licensing. Whatever, the TCK will here only be available free of charge to J2SE and J2EE licensees, not-for-profit entities and qualified individuals. Let me translate: in practice, the implementation of this JSR will be for "big bucks" companies and Apache only (typical price to license a TCK for a specific technology is always around 20.000$). I was personally expecting something more open for a JSR aimed at providing some kind of bridge between Java and languages such as PHP, Perl, etc...

    Bertrand Fontaine
    JavaShelf.com: Your Java bookstore on the Web!
  4. Jython et. al.[ Go to top ]

    There are (and have been for some time) implementations of various scripting languages for the Java VM. These implementations, of which Jython (Java Python) is perhaps the most famous, make it possible to hook into existing Java libraries, and they may already do more than 223 can deliver:

    "...Java devs claim that as written, JSR 223 could result in weak exception handling, poor performance and other drawbacks. In part, Frank Cohen, a developer using the Jython Open Source scripting language (based on Python) for Java, said:

    JSR 223 implements a very un-Java like way to bridge Java objects to script language functions. 223 aims to provide a native interface to make calls from a Java object to a limited number of common scripting functions. While there may be times when a native interface is useful, I would never like to include a native interface in my production-ready code. It's asking for problems."

    (Above from http://www.oetrends.com/cgi-bin/page_display.cgi?239)
  5. Jython et. al.[ Go to top ]

    I agree with PushToTest's thesis, "In my view, JSR 223 should be restarted. I believe Jython's use of Java byte codes is a much better design."

    My own objections are that this JSR overlooks three potentially lucrative scripting possibilities:

    1) Interpreting Java source as a scripting language.

    2) Building stand-alone desktop applications by using a fine-grained mix of scripts and classes, with bidirectional control flow.

    3) Allowing for executable XML, especially XUL and XSL.

    This JSR seems detrimentally slanted towards client/server applications with page based presentations. And Sun's obsession with PHP has done further damage to this JSR.
  6. The new JSR 223 (Scripting Pages in Java Webapps) aims at defining a way for

    > Java classes to be invoked from a page written in any scripting language.

     The JSR 223 is a joke. Why only support interop with PHP on the server for web pages? Is it because PHP is much more popular than Java and Sun want to use a trick from the Microsoft playbook called embrace, extend, extinguish?

     Why is Sun not more open and embraces scripting languages for the Java runtime?

     Is it because Sun's 10000 % pure Java doctrine treats dynamic scripting languages such as Python that let you do more with less (lines of code) as inferior bastards to Sun's one and only true love, the Java hard-core language?

      Let Sun know that you're not fooled and join the Viva! call to action to put pressure on Sun to truly embrace scripting languages.

      Full story @ http://viva.sourceforge.net/action.html
  7. Mr Bauer,

    I just have a few points issues and questions I would like to raise about your "Viva" movement.

    First of all I would like to say that I fully support the idea of an Open Source Java.

    Sun charging for Java use
    -----------------------------------
    Sun has far more to loss charging for java than what it gains it would cause the following problems
    - Cripple Java's fight against .Net, since Microsoft has distribution advantage, charging for Java certainly wouldn't help
    - cause alienation from open source movements like apache which even Sun admits has helped Java immensely, Tomcat is the most popular application server out there.
    - cause alienation from it's partners.
    - cause alienation from it's customers.
    - There will be no way they will reach 10 million developers, in fact only enterprises with significant investments in Java will pay up, I would say you will probably see developers flocking away from Java, turning Java into a "niche" legacy product.


    Boycott Swing
    --------------------
    bearing in mind that Swing hasn't really had mass adoption I don't really see it as much of a lock in, It's a standard and it is the only toolit that is lightweight and portable, ALL your listed toolkits are not, in fact they promote vendor lock in by the fact that they are facades to a third party windowing toolkit. I am glad for their existence though because it's forcing Sun to improve Swing.


    Boycott NetBeans
    ------------------------
    I don't use NetBeans anyway but will I have boycott jedit (www.jedit.org) as well since that is also written in the "evil" swing toolkit, in fact I will have to boycott every other program open source or otherwise written with Swing?

    Boycott Web Start
    --------------------------
    Hmm... what exactly is wrong here, Sun's (web start) JNLP implementation or the JNLP protocol, since NetX and OpenJNLP implement the JNLP protocol.

    Boycott the Java Cartel Process (JCP)
    ---------------------------------------------------
    Here at least I can partly agree with you, however it does seem that the member of the cartel that calls itself "Apache Software Foundation" seems to be quite active.

    Boycott Java Server Faces (JSF)
    -------------------------------------------
    Does mean we have to boycott Tomcat which will obviously contain the default reference implementation for JSF? Will I have to boycott Struts since JSF was pretty much designed by the guy who wrote Struts?

    Boycott Java.Net
    -----------------------
    will I have to boycott oreilly.net since that powers Java.Net?

    Embrace Scripting Languages for Java
    ---------------------------------------------------
    Absolutely, I think Java needs at least one simple additional language for the so called "Rank and file" developers. Was this an issue for you before .Net though?

    Embrace next-gen XML Markup Languages for rich UIs
    --------------------------------------------------------------------------
    Yeah!!!, I wan't to start coding with those Technologies now!!, where can I get some solid production class APIs?
  8. The new JSR 223 (Scripting Pages in Java Webapps) aims at defining a way for

    > > Java classes to be invoked from a page written in any scripting language.
    >
    >  The JSR 223 is a joke. Why only support interop with PHP on the server for web pages? Is it because PHP is much more popular than Java and Sun want to use a trick from the Microsoft playbook called embrace, extend, extinguish?
    >

    Oh, no, not this paranoid guy again... Man, can you read? You quoted the phrase that says just the opposite of what you just said!

    The reference implementation will focus on PHP, but the JSR (as is clearly written in the quote) will support any scripting language!!!
  9. this will ease dev. efforts[ Go to top ]

    But doesnt it mean PHP will just be JSP ?