beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
I see. Your biggest concern is that 'beansh' would be different from the upstream. But I think there are some reasons to support 'beansh'. 1. My opinion is to use both 'beanshell' and 'beansh', not 'beansh' only. 'beanshell' is for the potential name change in upstream, and beansh is use for short. 2. As far as I know, shell commands use 'sh' as the suffix of the command name, not 'shell'. Maybe that is another naming rule. 3. I don't think they will use other names, at least in a short term. Patrick Niemeyer /said "I had never heard that AIX was calling Bourne Shell bsh. I always thought Bourne shell was simply 'sh'. "/ Claire / /Garrett D'Amore wrote: > Claire Li wrote: >> Hi Garrett, >> >> Please see my in-line comments. >> >> Regards, >> Claire >> >> Garrett D'Amore wrote: >>> Claire Li wrote: Hi ARC team: In view of the naming conflict of bsh, I've contact beanshell author Patrick Niemeyer on this issue. He suggested resorting to name the command 'beanshell'. However, I would like to have both 'beanshell' and 'beansh' proposed by Jorg, since 'beansh' is more concise, and conciseness is what a command name needs. >>> >>> Conciseness *might* be useful, but IMO adding "beansh" doesn't make >>> that much sense if: >>> >>>1) the command is primarily executed from the gui >> The GUI of BeanShell is started by the command. >>>2) the command is infrequently manually type >> Everytime you want to start BeanShell, you need to type the command. >> So I think it's frequently manually typed. > > Ok. > >>>3) the upstream won't adopt the same change, so the change would >>> create "arbitrary" divergence from the upstream >> As far as I know, the upstream use 'bsh' as the command name. And so >> does the Linux platforms such as Ubuntu and Fedora. >> If we want to avoid the potential naming conflict, it seems we have >> to diverse from the upstream. > > My point was that, if the recommendation was to use "beanshell" from > upstream, then it is likely that this name will be available on other > platforms as well (perhaps in addition to "bsh"). The key thing here > is that for some platforms *in addition* to OpenSolaris, the bsh > conflict will exist. > > I remain unconvinced that saving 3 characters in the command name is > worth the risk of even *further* divergence from the upstream community. > > That said, I don't think I'll stand in the way of the alias if the > team wants to have it anyway. > >- Garrett >>> >>> My biggest concern of the three is #3. I think it would be wise to >>> stick with just what the upstream community advises. (If however >>> you get consensus from the upstream that "beansh" is a useful alias >>> and will be used on other platforms as well, then I'm happy to >>> support that option as well.) >>> >>>- Garrett >>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: beanshell 1.2. Name of Document Author/Supplier: Author: Claire Li 1.3 Date of This Document: 18 May, 2009 2. Project Summary 2.1 Project Description This project introduces the package of BeanShell 2.0b4 into the SFW consolidation. A minor release binding is requested. 4. Technical Description: BeanShell[1] is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. You can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education. BeanShell is small and embeddable, so you can call BeanShell from your Java applications to execute Java code dynamically at run-time or to provide extensibility in your applications. Alternatively, you can use standalone BeanShell scripts to manipulate Java applications; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same VM as your application, you can freely pass references to "live" objects into scripts and return them as results. In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package.
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
I'm marking this case closed approved. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
This case appears to have come to resolution, and the timeout has been reached. The package will provide the following command and link for beanshell: /usr/bin/beanshellUncommitted Command /usr/bin/beansh Uncommitted Symbolic link And the project team will monitor the application usage and upstream community to see if other command names should be used in the future. Cheers, Jim -- Jim Walker, http://blogs.sun.com/jwalker Sun Microsystems, Broomfield, Colorado
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Claire Li wrote: > I see. Your biggest concern is that 'beansh' would be different from > the upstream. But I think there are some reasons to support 'beansh'. > > 1. My opinion is to use both 'beanshell' and 'beansh', not 'beansh' > only. 'beanshell' is for the potential name change in upstream, and > beansh is use for short. > > 2. As far as I know, shell commands use 'sh' as the suffix of the > command name, not 'shell'. Maybe that is another naming rule. A "convention" perhaps, but not a rule. > > 3. I don't think they will use other names, at least in a short term. > Patrick Niemeyer /said "I had never heard that AIX was calling Bourne > Shell bsh. I always thought Bourne shell was simply 'sh'. "/ That's true for systems where /bin/sh is *not* ksh. Anyway, I don't care that much one way or the other -- I'd discourage "arbitrary" difference from the upstream, but whatever the project team wants to do is fine with me. -- Garrett > > > Claire > / > /Garrett D'Amore wrote: >> Claire Li wrote: >>> Hi Garrett, >>> >>> Please see my in-line comments. >>> >>> Regards, >>> Claire >>> >>> Garrett D'Amore wrote: Claire Li wrote: > Hi ARC team: > > In view of the naming conflict of bsh, I've contact beanshell > author Patrick Niemeyer > on this issue. He suggested resorting to name the command > 'beanshell'. > > However, I would like to have both 'beanshell' and 'beansh' > proposed by Jorg, > since 'beansh' is more concise, and conciseness is what a command > name needs. Conciseness *might* be useful, but IMO adding "beansh" doesn't make that much sense if: 1) the command is primarily executed from the gui >>> The GUI of BeanShell is started by the command. 2) the command is infrequently manually type >>> Everytime you want to start BeanShell, you need to type the command. >>> So I think it's frequently manually typed. >> >> Ok. >> 3) the upstream won't adopt the same change, so the change would create "arbitrary" divergence from the upstream >>> As far as I know, the upstream use 'bsh' as the command name. And so >>> does the Linux platforms such as Ubuntu and Fedora. >>> If we want to avoid the potential naming conflict, it seems we have >>> to diverse from the upstream. >> >> My point was that, if the recommendation was to use "beanshell" from >> upstream, then it is likely that this name will be available on other >> platforms as well (perhaps in addition to "bsh"). The key thing here >> is that for some platforms *in addition* to OpenSolaris, the bsh >> conflict will exist. >> >> I remain unconvinced that saving 3 characters in the command name is >> worth the risk of even *further* divergence from the upstream community. >> >> That said, I don't think I'll stand in the way of the alias if the >> team wants to have it anyway. >> >>- Garrett My biggest concern of the three is #3. I think it would be wise to stick with just what the upstream community advises. (If however you get consensus from the upstream that "beansh" is a useful alias and will be used on other platforms as well, then I'm happy to support that option as well.) - Garrett > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction >1.1. Project/Component Working Name: > beanshell >1.2. Name of Document Author/Supplier: > Author: Claire Li >1.3 Date of This Document: > 18 May, 2009 > > 2. Project Summary > 2.1 Project Description > > This project introduces the package of BeanShell 2.0b4 into > the SFW > consolidation. A minor release binding is requested. > > 4. Technical Description: > > BeanShell[1] is a small, free, embeddable Java source > interpreter with object > scripting language features, written in Java. BeanShell > dynamically executes > standard Java syntax and extends it with common scripting > conveniences such > as loose types, commands, and method closures like those in Perl > and > JavaScript. > You can use BeanShell interactively for Java experimentation > and debugging as > well as to extend your applications in new ways. Scripting Java > lends itself > to a wide variety of applications including rapid prototyping, > user scripting > extension, rules engines, configuration, testing, dynamic > deployment, > embedded systems, and even Java education. > > BeanShell is small and embeddable, so you can call BeanShell > from your Java > applications to execute Java code dynamically at run-time or to > provide > extensibility in your applications. Alternatively, you can use > standalone > BeanShell scr
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Claire Li wrote: > Hi ARC team: > > In view of the naming conflict of bsh, I've contact beanshell author > Patrick Niemeyer > on this issue. He suggested resorting to name the command 'beanshell'. > > However, I would like to have both 'beanshell' and 'beansh' proposed by > Jorg, > since 'beansh' is more concise, and conciseness is what a command name > needs. Thank you Claire! BTW: 'beansh' seems to be a good idea. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Hi Garrett, Please see my in-line comments. Regards, Claire Garrett D'Amore wrote: > Claire Li wrote: >> Hi ARC team: >> >> In view of the naming conflict of bsh, I've contact beanshell author >> Patrick Niemeyer >> on this issue. He suggested resorting to name the command 'beanshell'. >> >> However, I would like to have both 'beanshell' and 'beansh' proposed >> by Jorg, >> since 'beansh' is more concise, and conciseness is what a command >> name needs. > > Conciseness *might* be useful, but IMO adding "beansh" doesn't make > that much sense if: > >1) the command is primarily executed from the gui The GUI of BeanShell is started by the command. >2) the command is infrequently manually type Everytime you want to start BeanShell, you need to type the command. So I think it's frequently manually typed. >3) the upstream won't adopt the same change, so the change would > create "arbitrary" divergence from the upstream As far as I know, the upstream use 'bsh' as the command name. And so does the Linux platforms such as Ubuntu and Fedora. If we want to avoid the potential naming conflict, it seems we have to diverse from the upstream. > > My biggest concern of the three is #3. I think it would be wise to > stick with just what the upstream community advises. (If however you > get consensus from the upstream that "beansh" is a useful alias and > will be used on other platforms as well, then I'm happy to support > that option as well.) > >- Garrett > >> >> >> >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >>1.1. Project/Component Working Name: >> beanshell >>1.2. Name of Document Author/Supplier: >> Author: Claire Li >>1.3 Date of This Document: >> 18 May, 2009 >> >> 2. Project Summary >> 2.1 Project Description >> >> This project introduces the package of BeanShell 2.0b4 into the >> SFW >> consolidation. A minor release binding is requested. >> >> 4. Technical Description: >> >> BeanShell[1] is a small, free, embeddable Java source interpreter >> with object >> scripting language features, written in Java. BeanShell dynamically >> executes >> standard Java syntax and extends it with common scripting >> conveniences such >> as loose types, commands, and method closures like those in Perl and >> JavaScript. >> You can use BeanShell interactively for Java experimentation and >> debugging as >> well as to extend your applications in new ways. Scripting Java >> lends itself >> to a wide variety of applications including rapid prototyping, user >> scripting >> extension, rules engines, configuration, testing, dynamic deployment, >> embedded systems, and even Java education. >> >> BeanShell is small and embeddable, so you can call BeanShell from >> your Java >> applications to execute Java code dynamically at run-time or to >> provide >> extensibility in your applications. Alternatively, you can use >> standalone >> BeanShell scripts to manipulate Java applications; working with >> Java objects >> and APIs dynamically. Since BeanShell is written in Java and runs >> in the same >> VM as your application, you can freely pass references to "live" >> objects into >> scripts and return them as results. >> In short, BeanShell is dynamically interpreted Java, plus a >> scripting >> language and flexible environment all rolled into one clean package. >> >> Command name Notes >> === >> bshText mode >> bsh -g Grapphics mode >> >> 5. Interfaces >> >> Exported interfaceClassification >> Interface type >> === >> == >> SUNWbeanshell Uncommitted >> Package name >> /usr/bin/beanshUncommittedCommand >> /usr/bin/beanshell UncommittedCommand >> >> /usr/share/lib/java/bsh-2.0b4.jar Uncommitted >> Overall jar file >> /usr/share/lib/java/bsh-core-2.0b4.jar UncommittedCore >> interpreter >> /usr/share/lib/java/bsh-classgen-2.0b4.jar UncommittedClass >> generation >> /usr/share/lib/java/bsh-commands-2.0b4.jar UncommittedShell >> commands >> /usr/share/lib/java/bsh-util-2.0b4.jar Uncommitted >> Utilities >> >> /usr/share/lib/java/bsh-classpath-2.0b4.jarUncommitted >> Classpath >> >> management >> >> /usr/share/lib/java/bsh-reflect-2.0b4.jar Uncommitted >> Reflective >> >> accessibility >> >> /usr/share/lib/java/bsh-bsf-2.0b4.jar UncommittedBSF >> Adapter >> >> /usr/demo/bsh/webapps/bshservlet.war
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Hi ARC team: In view of the naming conflict of bsh, I've contact beanshell author Patrick Niemeyer on this issue. He suggested resorting to name the command 'beanshell'. However, I would like to have both 'beanshell' and 'beansh' proposed by Jorg, since 'beansh' is more concise, and conciseness is what a command name needs. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: beanshell 1.2. Name of Document Author/Supplier: Author: Claire Li 1.3 Date of This Document: 18 May, 2009 2. Project Summary 2.1 Project Description This project introduces the package of BeanShell 2.0b4 into the SFW consolidation. A minor release binding is requested. 4. Technical Description: BeanShell[1] is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. You can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education. BeanShell is small and embeddable, so you can call BeanShell from your Java applications to execute Java code dynamically at run-time or to provide extensibility in your applications. Alternatively, you can use standalone BeanShell scripts to manipulate Java applications; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same VM as your application, you can freely pass references to "live" objects into scripts and return them as results. In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package. Command name Notes === bshText mode bsh -g Grapphics mode 5. Interfaces Exported interfaceClassification Interface type === == SUNWbeanshell UncommittedPackage name /usr/bin/beanshUncommittedCommand /usr/bin/beanshell UncommittedCommand /usr/share/lib/java/bsh-2.0b4.jar UncommittedOverall jar file /usr/share/lib/java/bsh-core-2.0b4.jar UncommittedCore interpreter /usr/share/lib/java/bsh-classgen-2.0b4.jar UncommittedClass generation /usr/share/lib/java/bsh-commands-2.0b4.jar UncommittedShell commands /usr/share/lib/java/bsh-util-2.0b4.jar UncommittedUtilities /usr/share/lib/java/bsh-classpath-2.0b4.jarUncommittedClasspath management /usr/share/lib/java/bsh-reflect-2.0b4.jar UncommittedReflective accessibility /usr/share/lib/java/bsh-bsf-2.0b4.jar UncommittedBSF Adapter /usr/demo/bsh/webapps/bshservlet.war UncommittedTest servlvet example /usr/demo/bsh/webapps/bshservlet-wbsh.war UncommittedTest servlvet example Imported interfaces Classification Interface type === == == SUNWj6rtCommittedJDK 6.0 Runtime Env. (1.6.0_13) SUNWj6rtx CommittedJDK 6.0 64-bit Runtime Env. (1.6.0_13) Reference Documents === [1] http://www.beanshell.org/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open Jim Walker wrote: > I'm marking this case status as waiting needs spec. > > The project team will check with the beanshell community to > see how they have handled namespace issues in the past > and we will review the findings via email and hopefully > resolve at the next PSARC meeting on 05/13/2009. > > Cheers, > Jim
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Claire Li wrote: > Hi Garrett, > > Please see my in-line comments. > > Regards, > Claire > > Garrett D'Amore wrote: >> Claire Li wrote: >>> Hi ARC team: >>> >>> In view of the naming conflict of bsh, I've contact beanshell author >>> Patrick Niemeyer >>> on this issue. He suggested resorting to name the command 'beanshell'. >>> >>> However, I would like to have both 'beanshell' and 'beansh' proposed >>> by Jorg, >>> since 'beansh' is more concise, and conciseness is what a command >>> name needs. >> >> Conciseness *might* be useful, but IMO adding "beansh" doesn't make >> that much sense if: >> >>1) the command is primarily executed from the gui > The GUI of BeanShell is started by the command. >>2) the command is infrequently manually type > Everytime you want to start BeanShell, you need to type the command. > So I think it's frequently manually typed. Ok. >>3) the upstream won't adopt the same change, so the change would >> create "arbitrary" divergence from the upstream > As far as I know, the upstream use 'bsh' as the command name. And so > does the Linux platforms such as Ubuntu and Fedora. > If we want to avoid the potential naming conflict, it seems we have to > diverse from the upstream. My point was that, if the recommendation was to use "beanshell" from upstream, then it is likely that this name will be available on other platforms as well (perhaps in addition to "bsh"). The key thing here is that for some platforms *in addition* to OpenSolaris, the bsh conflict will exist. I remain unconvinced that saving 3 characters in the command name is worth the risk of even *further* divergence from the upstream community. That said, I don't think I'll stand in the way of the alias if the team wants to have it anyway. - Garrett >> >> My biggest concern of the three is #3. I think it would be wise to >> stick with just what the upstream community advises. (If however you >> get consensus from the upstream that "beansh" is a useful alias and >> will be used on other platforms as well, then I'm happy to support >> that option as well.) >> >>- Garrett >> >>> >>> >>> >>> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >>> This information is Copyright 2009 Sun Microsystems >>> 1. Introduction >>>1.1. Project/Component Working Name: >>> beanshell >>>1.2. Name of Document Author/Supplier: >>> Author: Claire Li >>>1.3 Date of This Document: >>> 18 May, 2009 >>> >>> 2. Project Summary >>> 2.1 Project Description >>> >>> This project introduces the package of BeanShell 2.0b4 into >>> the SFW >>> consolidation. A minor release binding is requested. >>> >>> 4. Technical Description: >>> >>> BeanShell[1] is a small, free, embeddable Java source interpreter >>> with object >>> scripting language features, written in Java. BeanShell >>> dynamically executes >>> standard Java syntax and extends it with common scripting >>> conveniences such >>> as loose types, commands, and method closures like those in Perl and >>> JavaScript. >>> You can use BeanShell interactively for Java experimentation and >>> debugging as >>> well as to extend your applications in new ways. Scripting Java >>> lends itself >>> to a wide variety of applications including rapid prototyping, >>> user scripting >>> extension, rules engines, configuration, testing, dynamic deployment, >>> embedded systems, and even Java education. >>> >>> BeanShell is small and embeddable, so you can call BeanShell from >>> your Java >>> applications to execute Java code dynamically at run-time or to >>> provide >>> extensibility in your applications. Alternatively, you can use >>> standalone >>> BeanShell scripts to manipulate Java applications; working with >>> Java objects >>> and APIs dynamically. Since BeanShell is written in Java and runs >>> in the same >>> VM as your application, you can freely pass references to "live" >>> objects into >>> scripts and return them as results. >>> In short, BeanShell is dynamically interpreted Java, plus a >>> scripting >>> language and flexible environment all rolled into one clean package. >>> >>> Command name Notes >>> === >>> bshText mode >>> bsh -g Grapphics mode >>> >>> 5. Interfaces >>> >>> Exported interfaceClassification >>> Interface type >>> === >>> == >>> SUNWbeanshell Uncommitted >>> Package name >>> /usr/bin/beanshUncommittedCommand >>> /usr/bin/beanshell UncommittedCommand >>> >>> /usr/share/lib/java/bsh-2.0b4.jar Uncommitted >>> Overall jar file >>> /usr/share/lib/java/bsh-core-2.0b4.jar UncommittedCore >>> interpreter >>> /usr/share/l
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Claire Li wrote: > Hi ARC team: > > In view of the naming conflict of bsh, I've contact beanshell author > Patrick Niemeyer > on this issue. He suggested resorting to name the command 'beanshell'. > > However, I would like to have both 'beanshell' and 'beansh' proposed > by Jorg, > since 'beansh' is more concise, and conciseness is what a command name > needs. Conciseness *might* be useful, but IMO adding "beansh" doesn't make that much sense if: 1) the command is primarily executed from the gui 2) the command is infrequently manually type 3) the upstream won't adopt the same change, so the change would create "arbitrary" divergence from the upstream My biggest concern of the three is #3. I think it would be wise to stick with just what the upstream community advises. (If however you get consensus from the upstream that "beansh" is a useful alias and will be used on other platforms as well, then I'm happy to support that option as well.) - Garrett > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction >1.1. Project/Component Working Name: > beanshell >1.2. Name of Document Author/Supplier: > Author: Claire Li >1.3 Date of This Document: > 18 May, 2009 > > 2. Project Summary > 2.1 Project Description > > This project introduces the package of BeanShell 2.0b4 into the SFW > consolidation. A minor release binding is requested. > > 4. Technical Description: > > BeanShell[1] is a small, free, embeddable Java source interpreter > with object > scripting language features, written in Java. BeanShell dynamically > executes > standard Java syntax and extends it with common scripting > conveniences such > as loose types, commands, and method closures like those in Perl and > JavaScript. > You can use BeanShell interactively for Java experimentation and > debugging as > well as to extend your applications in new ways. Scripting Java > lends itself > to a wide variety of applications including rapid prototyping, user > scripting > extension, rules engines, configuration, testing, dynamic deployment, > embedded systems, and even Java education. > > BeanShell is small and embeddable, so you can call BeanShell from > your Java > applications to execute Java code dynamically at run-time or to provide > extensibility in your applications. Alternatively, you can use > standalone > BeanShell scripts to manipulate Java applications; working with Java > objects > and APIs dynamically. Since BeanShell is written in Java and runs in > the same > VM as your application, you can freely pass references to "live" > objects into > scripts and return them as results. > In short, BeanShell is dynamically interpreted Java, plus a scripting > language and flexible environment all rolled into one clean package. > > Command name Notes > === > bshText mode > bsh -g Grapphics mode > > 5. Interfaces > > Exported interfaceClassification > Interface type > === > == > SUNWbeanshell Uncommitted > Package name > /usr/bin/beanshUncommittedCommand > /usr/bin/beanshell UncommittedCommand > > /usr/share/lib/java/bsh-2.0b4.jar Uncommitted > Overall jar file > /usr/share/lib/java/bsh-core-2.0b4.jar UncommittedCore > interpreter > /usr/share/lib/java/bsh-classgen-2.0b4.jar UncommittedClass > generation > /usr/share/lib/java/bsh-commands-2.0b4.jar UncommittedShell > commands > /usr/share/lib/java/bsh-util-2.0b4.jar UncommittedUtilities > > /usr/share/lib/java/bsh-classpath-2.0b4.jarUncommittedClasspath > > management > > /usr/share/lib/java/bsh-reflect-2.0b4.jar Uncommitted > Reflective > > accessibility > > /usr/share/lib/java/bsh-bsf-2.0b4.jar UncommittedBSF > Adapter > > /usr/demo/bsh/webapps/bshservlet.war UncommittedTest > servlvet > example > > /usr/demo/bsh/webapps/bshservlet-wbsh.war UncommittedTest > servlvet > example > > Imported interfaces Classification Interface type > === == == > SUNWj6rtCommittedJDK 6.0 Runtime Env. (1.6.0_13) > SUNWj6rtx CommittedJDK 6.0 64-bit Runtime Env. > (1.6.0_13) > > Reference Documents > === > [1] http://www.beanshell.or
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
I'm marking this case status as waiting needs spec. The project team will check with the beanshell community to see how they have handled namespace issues in the past and we will review the findings via email and hopefully resolve at the next PSARC meeting on 05/13/2009. Cheers, Jim
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
"Garrett D'Amore" wrote: > So, I guess the question here for ARC is whether "familiarity" with > Linux or familiarity with AIX is more important. I suspect I know the > answer, although were it up to me, I'd just skip the confusion by > denying *any* use of bsh going forward... Not using bsh for a newly introduced program may be a wise decision ;-) J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
James Carlson wrote: > > Please back up that statement on how you know that the majority of Sun > > customers use Blastwave. > > > > I don't believe you can make any such assertion since you do not have > > access to the data to back this up. > > Even if the majority do use Blastwave (which I'd be inclined to doubt; > though it's undoubtedly a large number who do, most Sun customers seem > to be commercial outfits that get hives when exposed to binaries > downloaded off the big bad Internet), that's not really the issue. > > The issue would be the number who've bothered to install 'schilyutils' > from opencsw.org (blastwave.org doesn't seem to have bsh) and then (of > those) who actually used /opt/csw/bin/bsh (the package delivers > several distinct things). It seems that you miss reality - sorry. I know that many in special commercial users install software from blastwave. The software from blastwave is even PGP signed You may like to ask Dennis about numbers. You may ask Dennis on how many people install cdrtools from Blastwave and schilyutils is a dependeny for cdrtools as it contains manpages that are needed as references for cdrtools. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
"Garrett D'Amore" wrote: > One person who publishes something 25 years ago doesn't get to impede > forward progress, or hold other projects hostage. Does this mean just because you don't know what happened before you are allowed to be hostile? Please don't > This is all the more true since it was probably difficult or impossible > for the beanshell folks to learn that "bsh" was a conflicting name. > > Since we don't have a "naming authority", we have to make the best > choices we can. If I were starting a new project, I'd agree, we should > choose a different name. But in this instance, the project is not > living in a vacuum, and your concerns, while noted, are overruled. We have naming helpers like sourcewell.berlios.de and freshmeat.net. Before I create a new project with a new name, I check whether the name I have in mind ist unique. I see no reason to support hostile software authors J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Jason King wrote: > Not sure if this will get out, but just to point out, even Sun's own > documentation (for other products -- often surrounding J2EE IIRC) > refers to bean shell as (bsh) -- it appears to be fairly well known by > that name within the Java community, so it's not really any particular > Linux distro. >From my investigations, "beanshell" was first published 8 years ago and does >not seem to be well known. "bsh" was first published ~25 years ago and is installed on many Solaris machines. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Norm Jacobs wrote: > > Do you like to copy this mistake? > > > Given the imperfection of our world, I'm going to side with what I > believe a majority of our customers will expect, so yes. The majority of the Sun customers seem to use blastwave and thus habe a bsh since many years. Do you really like to introduce a name clash for many Sun customers? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Darren J Moffat wrote: > being "my private shell" and /bin/beanshell being this case that is your > choice for your distro) - you have made no such indication and the fact > that you referred to it as "my private shell" seems to support that. > > I vote that we follow the practice of Fedora and Ubuntu on the grounds > of familiarity to far more people and the very people we are trying to > attract to OpenSolaris. I vote that we on Solaris do not break existing pratice and do not have two incompatible bsh programs. Blastwave users typically have the original bsh installed in /opt/csw/bin since many years and it does not seem to be a good idea to introduce something different under the name "bsh". J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Norm Jacobs wrote: > > Please use "beansh" > Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora > and Ubuntu appear to be BeanShell (I didn't check anywhere else). Given > that this is a familiarity case, wouldn't it make sense to install it in > the familiar location and have 'bsh' do the familiar thing? Many Solaris users have the real bsh (not the bean shell) under /opt/csw/bin/bsh. It may be different on Fedora or Ubuntu but on Solaris, there is a different history. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Joerg Schilling wrote: > Norm Jacobs wrote: > >>> Do you like to copy this mistake? >>> >> Given the imperfection of our world, I'm going to side with what I >> believe a majority of our customers will expect, so yes. > > The majority of the Sun customers seem to use blastwave and thus habe a bsh > since many years. Do you really like to introduce a name clash for many Sun > customers? Please back up that statement on how you know that the majority of Sun customers use Blastwave. I don't believe you can make any such assertion since you do not have access to the data to back this up. -- Darren J Moffat
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Darren J Moffat writes: > Joerg Schilling wrote: > > Norm Jacobs wrote: > > > >>> Do you like to copy this mistake? > >>> > >> Given the imperfection of our world, I'm going to side with what I > >> believe a majority of our customers will expect, so yes. > > > > The majority of the Sun customers seem to use blastwave and thus habe a bsh > > since many years. Do you really like to introduce a name clash for many Sun > > customers? > > Please back up that statement on how you know that the majority of Sun > customers use Blastwave. > > I don't believe you can make any such assertion since you do not have > access to the data to back this up. Even if the majority do use Blastwave (which I'd be inclined to doubt; though it's undoubtedly a large number who do, most Sun customers seem to be commercial outfits that get hives when exposed to binaries downloaded off the big bad Internet), that's not really the issue. The issue would be the number who've bothered to install 'schilyutils' from opencsw.org (blastwave.org doesn't seem to have bsh) and then (of those) who actually used /opt/csw/bin/bsh (the package delivers several distinct things). I'd be downright shocked if that number is anywhere near the number who'll be confused about /usr/bin/bsh because of: http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds1/bsh.htm ... and the same thing on HP/UX. /usr/bin/bsh being Bourne shell when /usr/bin/sh is Korn seems to be a semi-well-known pattern. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
As I also feared, "bsh" is also conflated with Bourne shell on other operating systems: http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds1/bsh.htm (The above is from AIX.) So, I guess the question here for ARC is whether "familiarity" with Linux or familiarity with AIX is more important. I suspect I know the answer, although were it up to me, I'd just skip the confusion by denying *any* use of bsh going forward... - Garrett Joerg Schilling wrote: > Norm Jacobs wrote: > > >>> Please use "beansh" >>> >> Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora >> and Ubuntu appear to be BeanShell (I didn't check anywhere else). Given >> that this is a familiarity case, wouldn't it make sense to install it in >> the familiar location and have 'bsh' do the familiar thing? >> > > Many Solaris users have the real bsh (not the bean shell) under > /opt/csw/bin/bsh. > > It may be different on Fedora or Ubuntu but on Solaris, there is a different > history. > > J?rg > >
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
"Garrett D'Amore" wrote: > >> Please use "beansh" > > Forgive me for pointing out the obvious here, but /usr/bin/bsh on > > Fedora and Ubuntu appear to be BeanShell (I didn't check anywhere > > else). Given that this is a familiarity case, wouldn't it make sense > > to install it in the familiar location and have 'bsh' do the familiar > > thing? > > It wasn't obvious -- not all of us have Ubuntu installations handy to > learn that. Well, what Ubuntu does is irrelevent. There is a simple rule: - The author first looks for a unique name and uses this name for a new project. - If someone implements mainly the same behavior, he may use the same name if this is tolerated by the original author. The alternative implementation needs to be put in a separate directory if someone likes to install it. - A program with completely different behavior needs to use a different name. The name "bsh" was defined 25+ years go by "H. Berthold AG Berlin" and published with a UNIX clone that was distributed. The name and the program are in contiguous use since then. The bean shell is not a well known program and it was written first 16 years later than "bsh" - the original program. The bean shell authors did not look for a unique name, so they cannot expect their choice name to be used outsice their home. It is bad practive to ignore historical facts, so I am in hope that Sun will not break things by polluting the name space. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Joerg Schilling wrote: > Norm Jacobs wrote: > >> Joerg Schilling wrote: >>> "Garrett D'Amore" wrote: >>> >>> My only small concern with this project is the name "bsh". ISTR being on other systems where "bsh" meant the "Bourne Shell". It seems like "beansh" might be a better name here to avoid possible confusion. But if this is widely deployed on FOSS already using "bsh", then perhaps we ought to leave the name as is. >>> "bsh" is used by my private shell for a much longer time (since 1984) than >>> people started to use "bsh" for the Bourne Shell. This is why I use "bosh" >>> for my extended Bourne Shell. >>> >>> Please use "beansh" >> Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora >> and Ubuntu appear to be BeanShell (I didn't check anywhere else). Given >> that this is a familiarity case, wouldn't it make sense to install it in >> the familiar location and have 'bsh' do the familiar thing? > > Do you like to copy this mistake? Exactly why is it a mistake ? Your private shell being called bsh is quite frankly irrelevant. It would only be relevant if there was an already existing or likely to be filed soon case to include it as part of the OpenSolaris distro (you can choose to do what ever you please in your distro - if you want /bin/bsh being "my private shell" and /bin/beanshell being this case that is your choice for your distro) - you have made no such indication and the fact that you referred to it as "my private shell" seems to support that. I vote that we follow the practice of Fedora and Ubuntu on the grounds of familiarity to far more people and the very people we are trying to attract to OpenSolaris. -- Darren J Moffat
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Norm Jacobs wrote: > Joerg Schilling wrote: > > "Garrett D'Amore" wrote: > > > > > >> My only small concern with this project is the name "bsh". ISTR being > >> on other systems where "bsh" meant the "Bourne Shell". It seems like > >> "beansh" might be a better name here to avoid possible confusion. But > >> if this is widely deployed on FOSS already using "bsh", then perhaps we > >> ought to leave the name as is. > >> > > > > "bsh" is used by my private shell for a much longer time (since 1984) than > > people started to use "bsh" for the Bourne Shell. This is why I use "bosh" > > for my extended Bourne Shell. > > > > Please use "beansh" > Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora > and Ubuntu appear to be BeanShell (I didn't check anywhere else). Given > that this is a familiarity case, wouldn't it make sense to install it in > the familiar location and have 'bsh' do the familiar thing? Do you like to copy this mistake?
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
"Garrett D'Amore" wrote: > My only small concern with this project is the name "bsh". ISTR being > on other systems where "bsh" meant the "Bourne Shell". It seems like > "beansh" might be a better name here to avoid possible confusion. But > if this is widely deployed on FOSS already using "bsh", then perhaps we > ought to leave the name as is. "bsh" is used by my private shell for a much longer time (since 1984) than people started to use "bsh" for the Bourne Shell. This is why I use "bosh" for my extended Bourne Shell. Please use "beansh". J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
On Wed, Apr 29, 2009 at 2:04 PM, Garrett D'Amore wrote: > Norm Jacobs wrote: >> >> Joerg Schilling wrote: >>> >>> Norm Jacobs wrote: >>> >>> Joerg Schilling wrote: > > "Garrett D'Amore" wrote: > > >> >> My only small concern with this project is the name "bsh". ?ISTR being >> on other systems where "bsh" meant the "Bourne Shell". ?It seems like >> "beansh" might be a better name here to avoid possible confusion. ?But if >> this is widely deployed on FOSS already using "bsh", then perhaps we >> ought >> to leave the name as is. >> > > "bsh" is used by my private shell for a much longer time (since 1984) > than people started to use "bsh" for the Bourne Shell. This is why I use > "bosh" > for my extended Bourne Shell. > > Please use "beansh" > Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora and Ubuntu appear to be BeanShell (I didn't check anywhere else). ?Given that this is a familiarity case, wouldn't it make sense to install it in the familiar location and have 'bsh' do the familiar thing? >>> >>> Do you like to copy this mistake? >>> >> >> Given the imperfection of our world, I'm going to side with what I believe >> a majority of our customers will expect, so yes. > > Okay, I'm going to say three things here: > > 1. ?I agree with Joerg that Ubuntu's decision (or possibly other upstream > sources) to name this "bsh" is probably a mistake, and unfortunate. > > 2. However, I agree with Darren and Norm, that the mistake/precedent is > already set by others (majority rule here), and changing the name will > probably just serve to increase confusion amongst our users. > > 3. ?Finally, +1 to the project as specified. > Not sure if this will get out, but just to point out, even Sun's own documentation (for other products -- often surrounding J2EE IIRC) refers to bean shell as (bsh) -- it appears to be fairly well known by that name within the Java community, so it's not really any particular Linux distro.
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Joerg Schilling wrote: > Norm Jacobs wrote: > > >> Joerg Schilling wrote: >> >>> "Garrett D'Amore" wrote: >>> >>> >>> My only small concern with this project is the name "bsh". ISTR being on other systems where "bsh" meant the "Bourne Shell". It seems like "beansh" might be a better name here to avoid possible confusion. But if this is widely deployed on FOSS already using "bsh", then perhaps we ought to leave the name as is. >>> "bsh" is used by my private shell for a much longer time (since 1984) than >>> people started to use "bsh" for the Bourne Shell. This is why I use "bosh" >>> for my extended Bourne Shell. >>> >>> Please use "beansh" >>> >> Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora >> and Ubuntu appear to be BeanShell (I didn't check anywhere else). Given >> that this is a familiarity case, wouldn't it make sense to install it in >> the familiar location and have 'bsh' do the familiar thing? >> > > Do you like to copy this mistake? > Given the imperfection of our world, I'm going to side with what I believe a majority of our customers will expect, so yes. -Norm
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Joerg Schilling wrote: > > The name "bsh" was defined 25+ years go by "H. Berthold AG Berlin" and > published with a UNIX clone that was distributed. The name and the program > are > in contiguous use since then. > No. "bsh" might have been in niche use, but it is not widely known by such use today; it is much more widely known as the Java tool then whatever shell was published 25 years ago. One person who publishes something 25 years ago doesn't get to impede forward progress, or hold other projects hostage. This is all the more true since it was probably difficult or impossible for the beanshell folks to learn that "bsh" was a conflicting name. Since we don't have a "naming authority", we have to make the best choices we can. If I were starting a new project, I'd agree, we should choose a different name. But in this instance, the project is not living in a vacuum, and your concerns, while noted, are overruled. Can we now stop talking about this? -- Garrett
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Joerg Schilling wrote: > "Garrett D'Amore" wrote: > > >> My only small concern with this project is the name "bsh". ISTR being >> on other systems where "bsh" meant the "Bourne Shell". It seems like >> "beansh" might be a better name here to avoid possible confusion. But >> if this is widely deployed on FOSS already using "bsh", then perhaps we >> ought to leave the name as is. >> > > "bsh" is used by my private shell for a much longer time (since 1984) than > people started to use "bsh" for the Bourne Shell. This is why I use "bosh" > for my extended Bourne Shell. > > Please use "beansh" Forgive me for pointing out the obvious here, but /usr/bin/bsh on Fedora and Ubuntu appear to be BeanShell (I didn't check anywhere else). Given that this is a familiarity case, wouldn't it make sense to install it in the familiar location and have 'bsh' do the familiar thing? -Norm
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Norm Jacobs wrote: > Joerg Schilling wrote: >> Norm Jacobs wrote: >> >> >>> Joerg Schilling wrote: >>> "Garrett D'Amore" wrote: > My only small concern with this project is the name "bsh". ISTR > being on other systems where "bsh" meant the "Bourne Shell". It > seems like "beansh" might be a better name here to avoid possible > confusion. But if this is widely deployed on FOSS already using > "bsh", then perhaps we ought to leave the name as is. > "bsh" is used by my private shell for a much longer time (since 1984) than people started to use "bsh" for the Bourne Shell. This is why I use "bosh" for my extended Bourne Shell. Please use "beansh" >>> Forgive me for pointing out the obvious here, but /usr/bin/bsh on >>> Fedora and Ubuntu appear to be BeanShell (I didn't check anywhere >>> else). Given that this is a familiarity case, wouldn't it make >>> sense to install it in the familiar location and have 'bsh' do the >>> familiar thing? >>> >> >> Do you like to copy this mistake? >> > Given the imperfection of our world, I'm going to side with what I > believe a majority of our customers will expect, so yes. Okay, I'm going to say three things here: 1. I agree with Joerg that Ubuntu's decision (or possibly other upstream sources) to name this "bsh" is probably a mistake, and unfortunate. 2. However, I agree with Darren and Norm, that the mistake/precedent is already set by others (majority rule here), and changing the name will probably just serve to increase confusion amongst our users. 3. Finally, +1 to the project as specified. - Garrett > >-Norm
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
Norm Jacobs wrote: > Joerg Schilling wrote: >> "Garrett D'Amore" wrote: >> >> >>> My only small concern with this project is the name "bsh". ISTR >>> being on other systems where "bsh" meant the "Bourne Shell". It >>> seems like "beansh" might be a better name here to avoid possible >>> confusion. But if this is widely deployed on FOSS already using >>> "bsh", then perhaps we ought to leave the name as is. >>> >> >> "bsh" is used by my private shell for a much longer time (since 1984) >> than people started to use "bsh" for the Bourne Shell. This is why I >> use "bosh" >> for my extended Bourne Shell. >> >> Please use "beansh" > Forgive me for pointing out the obvious here, but /usr/bin/bsh on > Fedora and Ubuntu appear to be BeanShell (I didn't check anywhere > else). Given that this is a familiarity case, wouldn't it make sense > to install it in the familiar location and have 'bsh' do the familiar > thing? It wasn't obvious -- not all of us have Ubuntu installations handy to learn that. -- Garrett > >-Norm
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
My only small concern with this project is the name "bsh". ISTR being on other systems where "bsh" meant the "Bourne Shell". It seems like "beansh" might be a better name here to avoid possible confusion. But if this is widely deployed on FOSS already using "bsh", then perhaps we ought to leave the name as is. -- Garrett James Walker wrote: > I'm sponsoring this familiarity case for Claire Li. The requested > release binding is minor. The man page has been posted in the > materials directory. > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: >beanshell > 1.2. Name of Document Author/Supplier: >Author: Claire Li > 1.3 Date of This Document: > 29 April, 2009 > 4. Technical Description > > 2. Project Summary >2.1 Project Description > >This project introduces the package of BeanShell 2.0b4 into the SFW >consolidation. A minor release binding is requested. > > 4. Technical Description: > >BeanShell[1] is a small, free, embeddable Java source interpreter with > object >scripting language features, written in Java. BeanShell dynamically > executes >standard Java syntax and extends it with common scripting conveniences such >as loose types, commands, and method closures like those in Perl and >JavaScript. > >You can use BeanShell interactively for Java experimentation and debugging > as >well as to extend your applications in new ways. Scripting Java lends > itself >to a wide variety of applications including rapid prototyping, user > scripting >extension, rules engines, configuration, testing, dynamic deployment, >embedded systems, and even Java education. > >BeanShell is small and embeddable, so you can call BeanShell from your Java >applications to execute Java code dynamically at run-time or to provide >extensibility in your applications. Alternatively, you can use standalone >BeanShell scripts to manipulate Java applications; working with Java > objects >and APIs dynamically. Since BeanShell is written in Java and runs in the > same >VM as your application, you can freely pass references to "live" objects > into >scripts and return them as results. > >In short, BeanShell is dynamically interpreted Java, plus a scripting >language and flexible environment all rolled into one clean package. > >Command name Notes >=== >bshText mode >bsh -g Grapphics mode > > 5. Interfaces > >Exported interface Classification Interface type >= == == >SUNWbeanshell Uncommitted Package name >/usr/bin/bsh Uncommitted Command > >/usr/share/lib/java/bsh-2.0b4.jar Uncommitted Overall jar file >/usr/share/lib/java/bsh-core-2.0b4.jar Uncommitted Core interpreter >/usr/share/lib/java/bsh-classgen-2.0b4.jar Uncommitted Class generation >/usr/share/lib/java/bsh-commands-2.0b4.jar Uncommitted Shell commands >/usr/share/lib/java/bsh-util-2.0b4.jar Uncommitted Utilities > >/usr/share/lib/java/bsh-classpath-2.0b4.jarUncommitted > Classpath > management > >/usr/share/lib/java/bsh-reflect-2.0b4.jar Uncommitted Reflective > accessibility > >/usr/share/lib/java/bsh-bsf-2.0b4.jar Uncommitted BSF Adapter > >/usr/demo/bsh/webapps/bshservlet.war Uncommitted Test > servlvet > example > >/usr/demo/bsh/webapps/bshservlet-wbsh.war Uncommitted Test servlvet > example > >Imported interfaces Classification Interface type >=== == == >SUNWj5rt Committed JDK 5.0 Runtime Env. (1.5.0_18) >SUNWj5rtx Committed JDK 5.0 Runtime Env 64bit. (1.5.0_18) > > (plan to use JDK 6.0 after additionaly testing) > >Reference Documents >=== >[1] http://www.beanshell.org/ > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > >
beanshell [PSARC/2009/270 FastTrack timeout 05/06/2009]
I'm sponsoring this familiarity case for Claire Li. The requested release binding is minor. The man page has been posted in the materials directory. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: beanshell 1.2. Name of Document Author/Supplier: Author: Claire Li 1.3 Date of This Document: 29 April, 2009 4. Technical Description 2. Project Summary 2.1 Project Description This project introduces the package of BeanShell 2.0b4 into the SFW consolidation. A minor release binding is requested. 4. Technical Description: BeanShell[1] is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript. You can use BeanShell interactively for Java experimentation and debugging as well as to extend your applications in new ways. Scripting Java lends itself to a wide variety of applications including rapid prototyping, user scripting extension, rules engines, configuration, testing, dynamic deployment, embedded systems, and even Java education. BeanShell is small and embeddable, so you can call BeanShell from your Java applications to execute Java code dynamically at run-time or to provide extensibility in your applications. Alternatively, you can use standalone BeanShell scripts to manipulate Java applications; working with Java objects and APIs dynamically. Since BeanShell is written in Java and runs in the same VM as your application, you can freely pass references to "live" objects into scripts and return them as results. In short, BeanShell is dynamically interpreted Java, plus a scripting language and flexible environment all rolled into one clean package. Command name Notes === bsh Text mode bsh -g Grapphics mode 5. Interfaces Exported interface Classification Interface type === == SUNWbeanshellUncommitted Package name /usr/bin/bsh Uncommitted Command /usr/share/lib/java/bsh-2.0b4.jarUncommitted Overall jar file /usr/share/lib/java/bsh-core-2.0b4.jar Uncommitted Core interpreter /usr/share/lib/java/bsh-classgen-2.0b4.jar Uncommitted Class generation /usr/share/lib/java/bsh-commands-2.0b4.jar Uncommitted Shell commands /usr/share/lib/java/bsh-util-2.0b4.jar Uncommitted Utilities /usr/share/lib/java/bsh-classpath-2.0b4.jar Uncommitted Classpath management /usr/share/lib/java/bsh-reflect-2.0b4.jarUncommitted Reflective accessibility /usr/share/lib/java/bsh-bsf-2.0b4.jarUncommitted BSF Adapter /usr/demo/bsh/webapps/bshservlet.war Uncommitted Test servlvet example /usr/demo/bsh/webapps/bshservlet-wbsh.warUncommitted Test servlvet example Imported interfaces Classification Interface type === == == SUNWj5rt Committed JDK 5.0 Runtime Env. (1.5.0_18) SUNWj5rtxCommitted JDK 5.0 Runtime Env 64bit. (1.5.0_18) (plan to use JDK 6.0 after additionaly testing) Reference Documents === [1] http://www.beanshell.org/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: SFW 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
