The Artima Developer Community
Sponsored Link

Java Community News
Scripting for the Java Platform

5 replies on 1 page. Most recent reply: Jul 27, 2006 11:02 PM by Luis Sergio Oliveira

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Scripting for the Java Platform Posted: Jul 26, 2006 9:05 AM
Reply to this message Reply
Summary
A recent Sun Developer Network article gives a detailed overview of using JSR 223 to embed scripting languages in your Java application.
Advertisement

In Scripting for the Java Platform, author John O'Conner walks through an example of using a JSR 223 script engine to embed a scripting language into a Java application. He provides as an example a Java calculator application that allows users to customize the calculator by writing JavaScript.

He suggests several reasons you may wish to embed a scripting language into a Java application:

  • Sophisticated configuration options.
  • User-defined functionality.
  • Ease of maintenance after application release.
  • Skill sets of users -- end users may be familiar with scripting languages but not the Java programming language.
  • Reuse of code modules in other programming languages.

Do you have plans for embedding a scripting language into a Java application? If so, why?


Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

Re: Scripting for the Java Platform Posted: Jul 26, 2006 2:14 PM
Reply to this message Reply
Hello Bill,

I worked in a project for a mediation platform where we made the bulk of the application in Java and only left the mapping parts to be written in a scripting language. Then the mapping could be developed without compilation and with live hardware, making the actual development a highly iteractive experience. It was almost fun :-)

The main idea was that customers could add new hardware without a huge pain...

It worked very well and we replaced a XML rule based mediation platform with great success in productivity and performance.

The fact that we used Jython made everything better. Jython doesn't support JSR 223 yet, though...

Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: Scripting for the Java Platform Posted: Jul 27, 2006 6:39 AM
Reply to this message Reply
There has always been a trade-off between the safety of static type-checking and user flexibility. If we could allow methods to be overridden not merely on the basis of the types of input arguments, but also by result returned, a typed language could have the same benefits. Unfortunately, static type checking may not be possible with this kind of polymorphism.

Still, Java's static type system is not bullet-proof. We do allow casts whose success can only be determined at runtime. Perhaps all Java needs is a few conversion functions that take arbitrary objects as input and return the expected type, usually doing the right thing but raising an exception when there is not obvious mapping from the input object to an object of the desired type..

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Scripting for the Java Platform Posted: Jul 27, 2006 3:27 PM
Reply to this message Reply
> I worked in a project for a mediation platform where we
> made the bulk of the application in Java and only left the
> mapping parts to be written in a scripting language. Then
> the mapping could be developed without compilation and
> with live hardware, making the actual development a highly
> iteractive experience. It was almost fun :-)
>
Sounds neat, but what is a "mediation platform"?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Scripting for the Java Platform Posted: Jul 27, 2006 3:31 PM
Reply to this message Reply
> There has always been a trade-off between the safety of
> static type-checking and user flexibility. If we could
> allow methods to be overridden not merely on the basis of
> the types of input arguments, but also by result returned,
> a typed language could have the same benefits.
> Unfortunately, static type checking may not be possible
> e with this kind of polymorphism.
>
If I remember my reading of the JVM spec, that kind of overriding is possible at the class file level, because methods are described with method "descriptors," which include the return type, as opposed to method "signatures," that exclude the return type. My understanding was that the main reason you can't overload on return type in Java (or C++ for that matter) was that at the source level, when invoking a so-overloaded method without using the return type, the compiler wouldn't be able to figure out which overloaded option you meant.

Luis Sergio Oliveira

Posts: 22
Nickname: euluis
Registered: Jan, 2004

mediation platform Posted: Jul 27, 2006 11:02 PM
Reply to this message Reply
> > I worked in a project for a mediation platform where we
> > (...)
> Sounds neat, but what is a "mediation platform"?

Specifically it enabled building integration between Telco Network Management Systems (NMS) and Telco Network Elements (NEs). Each NMS normally has its own information model and we have to map the NEs information to that. Also on the NE side you have several standards (SNMP, Q3, Qx, XML dialects) that must be handled differently.

Flat View: This topic has 5 replies on 1 page
Topic: Scripting for the Java Platform Previous Topic   Next Topic Topic: Ajax and Spring with the TIBCO General Interface

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use