Java trends: Scripting languages

Discussions

News: Java trends: Scripting languages

  1. Java trends: Scripting languages (16 messages)

    Chris Preimesberger looks at the increasing incidence of scripting languages in the Java realm and the pluses and minuses of using them. His pro's are: rapid development, ease of deployment, integration with existing technologies, easy to learn and use, dynamic code.

    Are more and more scripting technologies like Jython, BeanShell and Jess the future?

    There have always been people that say something like:

    - scripting languages are great. I don't want to mess with casting ... typing is evil, and I can get so much more done without it.

    - scripting languages are evil. They are all just hacks

    - There are different jobs that suit different solutions. There is a place for scripting languages, and a time not to use them.

    Are Java developers really using more scripting languages now than before? Is it a more important part of our toolbox? If so, which ones!

    "This scripting trend is being driven largely by rapid application development (RAD), a development style that is gaining disciples all the time. As marketing executives put the full-court press on IT shops to speed production, IT managers are forced to look at the most efficient ways to beat deadlines. RAD is a prime mover here."

    Read the complete story: Java trends: Scripting languages
  2. I also invite you to check out my JUG Austria talk slides in an all-in-one HTML version (no PowerPoint, thank you) entitled "Python and Jelly: Scripting Power for Java and XML: Do More With Less (Lines Of Code)".

    It's a fast-paced, example packed Python Scripting intro for Java Hackers (40+ slides).

    Enjoy.
  3. It's a fast-paced, example packed Python Scripting intro for Java Hackers (40+ slides).

    Imagine a Java program where every method parameter is declared as Object. That's Python.
  4. Trend leaded by the market ![ Go to top ]

    When the business is going down, the main message is : do quick (and even dirty, just to make business and survive !).
    When the business was up - remember the 00's - , the message was "do best with UML, design patterns & layered applications", i.e. the opposite of the "scripting" trend.

    My opinion: scripting is just a fashion cause it allows to work quite quickly, i.e. without big investments from IT Departments. When big projects will coming out to the market, the "scripting" solutions would fail. Why ? Because re-use and maintenance of such "scripting-based" applications is too hard, and even unefficient or impossible !

    Yann
  5. Re: Trend leaded by the market ![ Go to top ]

    Whether the increase in usage of scripting languages in the world of Java is a result of lack of funding in the world of IT (and it very well may be) it is erroneous to assume that scripting languages are merely a "trend". On the contrary I believe that a mix of scripting and non-scripting languages will always provide the best result for both small and large applications.

    It just so happens that in the world of Java developers are getting tired of having to write so much code when a scripting solution integrated with the Java APIs would suffice.

    Sincerely,
    Anthony Eden
  6. Scripting is cool, but...I'm not sure what the time savings would be for me without IDE support. What I really need is code completion for XML, JSP, Jelly etc. in a solid IDE like Eclipse. Without IDE hints, I find the mental switching time tough to take. Anyone know of any decent (and free;)) scripting plugins for eclipse? I took a look at Jelly today, and while it looks great the mind balks, initially, at the thought of stuffing another language in there.
  7. Re: Trend leaded by the market ![ Go to top ]

    And the problem of scripting languages (I add to these languages the several DTDs we use...looks more and more like scripting languages) is that main frameworks (e.g. java presentation frmeworks) run their OWN syntax; a web-based project may now require 5 to 10 languages !

    So, the 'easy-to-use' argument is counterbalanced by this required knowledge. And as u know there are 'best practices' for each language, can you imagine the long-run before programming in a good way with scripting languages ?

    Yann
  8. On the contrary I believe that a mix of scripting

    > and non-scripting languages will always provide the
    > best result for both small and large applications.

    I agree 100% with you, Anthony. In fact I have been looking at your JPublish framework (I currently use 2.05b, from CVS). I think that it is very nice framework (and I have used Struts, WebWork and Maverick, so far). I'm currently building a site for our football team and I'm willing to donate it back to you when I'm ready (as a sample application).

    I use mainly Jython. It is really wonderfull thing that you can program business code with dynamic language. I know also some big projects that have been implemented completely with PHP or other scripting based language. And I know that they work very well.

    I'm going to implement all the functionality I need with Jython with support of some great Java libraries. If I have problems with performance I will look at implementing those parts with compiled Java (or maybe I use something to cache the performance bottle necks). I'm also thinking about using Hibernate (I know that product very well), but maybe I just go with zxJDBC (at least with the first implementation) and use JNDI to store my DataSource. It's so easy that I'm pretty amazed about the power that scripting gives to me. For example if I need to retrieve something simple from database I could write something like this:

    from com.ziclix.python.sql import zxJDBC

    cn = zxJDBC.lookup("java:comp/env/jdbc/MyDataSouce")
    cursor = cn.cursor(1)
    cursor.execute("SELECT * FROM some_table")

    I'm not saying that scripting would fit on every situations, but for web based applications it really gives so much, that I'm not willing to spend my time on writing Java classes. And yes, I like the page-based approach that you have selected in your framework. WebWork, Struts and Maverick use Action-based approach and it doesn't look right to me (with all that chaining and intercepting) when it comes to building web-apps. In fact Portlet API will look somewhat similar what comes to page-based approach.

    > It just so happens that in the world of Java
    > developers are getting tired of having to
    > write so much code when a scripting solution
    > integrated with the Java APIs would suffice.

    I'm not as tired of writing Java code as I'm tired of compilation phase, that is really not needed in many situations as scripting language can provide you the same features with less code, quiker testing and on-the-fly modifications. It's really a pleasure to make quick modifications over SSH with simple text editor. I know that good servlet engine will compile .java files on-the-fly, but that's not the same as using simpler scripting.

    Some have argued that scripting will cause maintenance problems. If you ask me, I can say that they are wrong. You can write unmaintainable code with java too. It's not the language. It is the design. And it's not very difficult to port Jython classes (or BeanShell) to Java after all when you need that.

    Scripting on top of mature Java libraries is really an advantage.
  9. The real trick to most applications is generating the string "SELECT * FROM some_table." The process isn't isn't computationally intensive, but it can be a very complex process, and has a tendency to become even more so over time. Most of the other problems have been solved. Storage, persistence, transactions, caching, network communication, presentation, etc., all have multiple frameworks that do the work for you.

    A scripting language can be thought of as the framework for business logic. As an added bonus, it turns out that it is also good at simplifying many of the implementation details as well.
  10. Right under your nose[ Go to top ]

    Java users have been using scripting languages for some time, they just don't recognize them as such. JVM languages such as ANT, JSP, and XDoclet save developers an enormous amount of time, yet we don't recognize them as scripting languages because they are so integrated into the Java way of doing things.
  11. Right under your nose[ Go to top ]

    ANT, JSP, and XDoclet save developers an enormous amount of time, yet we don't >recognize them as scripting languages


     try google Ant Script and see how many you get, it will be quite a lot
  12. Great article about scripting languages:
    http://home.pacbell.net/ouster/scripting.html
  13. Jython makes a very nice bridge[ Go to top ]

    One thing the article seems to miss is that scripting languages are getting popular because scripting languages provide a symantec definition for a program. Jython, for example, provides the ability to symantecally define a set of steps to take, and to define the flow from one step to another. Doing the same thing in Java is possible, of course, but a scripting language like Jython includes the symantecs for defining a script, whereas Java makes you create that symantec definition for yourself.

    I'm the principal maintainer for an open-source test framework and utility that uses both Java and Jython. TestMaker (details at http://www.pushtotest.com/ptt) embeds Jython to provide a script language that non-Java coders can use to build test scripts (I call them agents.) I implement an extensible, reusable, object-oriented library of protocol handlers (HTTP, SOAP, XML-RPC, etc.) that is called from the Jython scripts.

    I chose Jython because it compiles native Java bytecodes, so I get the benefit of having a scripting language and full access to both Java and Python objects. I find this approach to be the best - and my hat is off to the Jython team.

    One last thing, Java and Jython still impress me for being able to handle lots of concurrently running threads. In the past 18 months the dymanic duo have run flawlessly.

    -Frank Cohen
    http://www.PushToTest.com
  14. There are some places in J2EE, where it is commonly appreciated, that java won't do the job. Look at the new Expression Language in JSP 2.0. It is used, where non-java developers (as web designers) need to write some limited amount of functionality, like evaluating and comparing values in conditions or value converting tasks, "on top of" j2ee software. At this place, scripting languages are a perfect fit.

    As this JSP expression language is not yet implemented anywhere, we use the "Rhino"-Implementation of JavaScript 1.5, hosted by the mozilla project, to do this task in our content management solution and are quite happy with it, so I can recommend it.
    It's main features are:

    - Already a well known language. Most web designers know javascript. They only have to work with the objects you supply them instead of the browser objects document, window etc.

    - You can supply any java object to the scripting runtime, entirely without interfacing tasks. Getter and setter methods are converted to js objects properties, so obj.getName() and obj.setName() can be used as:

    obj.name = "xyz"

    - You can precompile scripts to function objects and execute them many times without the overhead of parsing the script again and again

    We favoured it instead of Jython, because python as a language seems to be still quite unknown to web designers and the fact that whitespaces "matters" there might be problematic, because our scripts are used inside JSP-custom-tags, a domain where Whitespace (at least outside of Java-Scriptlets) normally is ignored.

    You can get it here, if you're interested:
    http://www.mozilla.org/rhino/
  15. Agreed,

    You'll notice that about alot of templating engines. For example webmacro, the developer supplies the objects, the page cutters just print them out. Simplistic syntax.
  16. Not implemented? Try http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html
  17. Scheme in a JVM[ Go to top ]

    I really like the various Schemes that run under the JVM. Some of them
    are interpreted while others compile down to Java byte codes. It's very
    pleasant to be able to use a powerful language such as Scheme in a
    Java program.

    Kawa (http://www.gnu.org/software/kawa) is very nice, as is JScheme (http://jscheme.sourceforge.net/jscheme/mainwebpage.html).