Re: BeanShell alternatives (was Re: Status of projectand adding 1.5 generics)

This subject arose 18 months ago. See for my feelings at the time:

http://sourceforge.net/mailarchive/message.php?msg_id=148438.29107.qm%40web60019.mail.yahoo.com

Beanshell uses javacc to parse the input. The syntax file it uses has developed over time and contains many look aheads and exceptions. It is inefficient and difficult to change. Compare it with the syntax file distributed now with javacc for parsing Java 6. Any syntax changes to Beanshell would probably be best done by replacing its syntax file with a new one based on the official Java 6 one.

Switching seamlessly between Beanshell and Java is a falicy as the following error reports show Java and Beanshell produce opposite results for the same program.

1272396 Problem throwing an exception 
1272387 Interfaces need not have java.lang.Object as
superclass 
1255984 Problem to continue to a label 
1255937 An exception in break label 
1246854 using an InputStream 
1246841 using a GUI Swing type style of Java 
1237615 BeanShell's handling of
java.lang.NullPointerException 
1225665 byte b3 = 1; byte b4 = -b3; //should not
compile 
1225617 BeanShell's automatic casts are more
restrictive than Java 
1225612 bsh.TokenMgrError: Lexical error at line 1,
column 127. Enc 
1225607 Exception in thread "main"
bsh.Parser$LookaheadSuccess 
1221313 Runtime error using forward referrence 
1221300 Runtime error (Target Exception) using super 
1106071 Comparing Strings dependant on how they are
instanciated 

I feel that the first step in Leading an offshoot of Beanshell is to make and achieve agreement on a list of bugs to be fixed in the base of the offshoot.

--- On Wed, 10/12/08, Paul Reavis <[email protected]> wrote:

> From: Paul Reavis <[email protected]>
> Subject: Re: [Beanshell-dev] BeanShell alternatives (was Re: Status of projectand adding 1.5 generics)
> To: "David A. Lee" <[email protected]>
> Cc: Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, [email protected]
> Date: Wednesday, 10 December, 2008, 7:51 PM
> On Dec 10, 2008, at 2:12 PM, David A. Lee wrote:
> 
> > I talked with my partner today and we decided to stay
> with BeanShell.
> > We've been using it for several years in
> production and it would be  
> > difficult to extract,
> > and there's no compelling reason to change except
> the "FUD" of it  
> > being "not supported".
> > That's still a concern but not big enough to cause
> us to want to  
> > toss it.
> > We have the source and the know-how if we need to
> spot-fix  
> > something ...
> > In fact even today I'm integrating in BSH support
> to our other  
> > product line under the philosophy that sharing the
> same technology  
> > across products is a good thing.
> >
> > So not only is BSH alive and well ... but its being
> continued in new  
> > projects .. atleast in my shop.
> 
> I think that will be the defacto case here. Rather than
> "switch" we  
> will probably just tend towards supporting a variety of
> scripting  
> languages. Which one should be the canonical one for
> training,  
> documentation, and other work is another question but
> doesn't really  
> affect what we'll need to do regarding BeanShell.
> 
> > Given that I would LOVE some kind of semi-active
> semi-official  
> > handover of the codebase to dedicated maintainers, and
> volunteer to  
> > be one of them.
> > the beanshell2 google fork is a good thing, I have
> contributed to it  
> > in the past, but I think its goals are different then
> what I  
> > suggest.  I suggest a fork who's #1 main goal is
> stability and  
> > minimum changes.  Bug fixes only ... and MAYBE a path
> towards new  
> > java syntax support ... but not new features, and
> heavily focused on  
> > maintaining legacy use.  I think thats a fundamentally
> different  
> > goal then a "new and better beanshell" which
> is also a good goal ...  
> > but not the one I'm most interested in personally.
>   To achieve this  
> > goal I suspect will require some kind of
> "committee" so that no  
> > individual is tempted to make changes without
> consensus or  
> > oversight.  Of course that slows things down and is
> inefficient ...  
> > but then that's the point.
> 
> I completely agree.
> 
> I think we need:
> 1) official website with version control and project
> management
> 2) one or more official leaders
> 3) a near-term stable release based on the latest beta
> 4) clean pedigree
> 
> Is Pat reading this? I certainly don't want to discount
> his work so  
> far, lock him out, or force a coup. My impression is that
> he has good  
> intentions and not enough time (much like all of us I
> suspect).
> 
> Partner Software and I can offer:
> 1) our own fixes (vararg support, 1.5-style exception
> chaining,  
> support for parse-once-run-many)
> 2) developer resources (I've been programming in Java
> for 11+ years,  
> we have three other full-time Java programmers, and
> it's the  
> foundation of our platform)
> 3) testing and release management resources
> 4) web sites (we use DreamHost for the most part, though
> one of the  
> standard "foundry" sites might be more
> appropriate)
> 5) physical facilities in Athens, GA - we have a good
> relationship  
> with area hotels and have meeting rooms etc.
> 6) some funding
> 
> I am willing to provide leadership but I am extremely busy
> and may not  
> be the best choice.
> 
> The quantity of resources provided will be dictated by
> enlightened  
> self interest. We don't expect financial compensation
> but we do have a  
> business to run so can't drop everything to focus on
> BeanShell issues.  
> If we do decide to move our attention to another language
> then our  
> interest in BeanShell will be largely to ensure legacy
> support.
> 
> What I want from BeanShell is:
> 1) ability to parse JLS-compliant Java source
> 2) ability to parse a variant of Java that is very close to
> JLS- 
> compliant Java, but that allows:
> * loosely typed variables
> * procedural-style programming (code that's not in an
> explicit method  
> and methods that aren't in an explicit class)
> * "shell" style terminal usage
> 3) stability
> 4) performance
> 
> Porting back and forth from BeanShell to Java should
> consist of little  
> more than putting the code in proper methods and classes
> and assigning  
> types to all variables. Porting from Java to BeanShell
> should be a non- 
> issue; I think BeanShell should be able to parse Java
> directly. It's  
> pretty close already.
> 
> I like a little syntactic sugar - especially multiline
> strings - but I  
> think if you add much of that stuff then you end up with
> Groovy so why  
> go that route? I think the topic is worth debating, though.
> Embedding  
> variables in strings, multiline strings, etc. are all very
> useful in a  
> scripting language. However it does detract from the ease
> of porting  
> back to Java.
> 
> Regardless I think BeanShell should have a clear vision and
> niche. It  
> won't be perfect for all uses, or make everyone happy
> no matter what  
> we pile on.
> 
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in
> Las Vegas, Nevada.
> The future of the web can't happen without you.  Join
> us at MIX09 to help
> pave the way to the Next Web now. Learn more and register
> at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Beanshell-developers mailing list
> Beanshell-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/beanshell-developers


      

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/