Blockers for v3.0.0 Release

[jimjag]

Is see that there are some bugs noted, but are there any real blockers holding up a v3.0.0 release?

[nickl-]

The core outstanding issues tally up to 19 and if we include the GUI defects there are 27 remaining.

Getting these crunched, especially the sourceforge issues, are still a priority.

I do feel the issues remaining on #694 are critical, perhaps not the late binding perse but the reload of types changed is a real nuisance. It would of course help if I had even the slightest clue how we are going to resolve them, made several attempts already but they all went /dev/null.

There does seem to still be more nagging issues that keep popping up, which haven't been reported yet, it would be a bonus if we can get more exposure of the SNAPSHOT release to get reports on the most obvious dents to hammer down. Especially some feedback on what 3.0.0 does to existing 2.b workloads would be helpful to know. This will really go a long way to ensure a stable release...

[opeongo]

I am still not able to use V3 for my workloads. It is a combination of small issues (like #725 and #726), deeper issues (#659) and planned incompatibilities (e.g. variable scoping changes). I know that the small issues will get fixed, and so will #659 eventually.

The variable scoping change will bite on large code bases. For people who are using V2 scripts that someone else has developed this will be a big pain point. I would like to implement a compatibility flag (with a default value of false) that will allow the previous V2 behaviour. Think of this as a transitional mode to help people make the switch. New code will use the new scoping rules. Old code can set the compatibility flag in order to run correctly without requiring changes. I have had a look and this can be implemented as a small non-intrusive change. If I send in a PR for this would it be considered?

[nickl-]

I have had a look and this can be implemented as a small non-intrusive change.

It is not a small change.

Old code can set the compatibility flag in order to run correctly without requiring changes.

Adding the super. to place the variable in global scope seems like an easy enough compromise. In most cases it won't be obscure and declaring the variable in the parent scope will be just as easy, which is what you want to do anyway.

If this is all that breaks I am sure we will be forgiven. There really is no good reason why this is acceptable scope usage, may as well throw braces away completely.

[opeongo]

It is not a small change.

Seems to be a small non-intrusive change, have a look at #727. Could you help me out and explain what I overlooked that makes this more than a small change?

Old code can set the compatibility flag in order to run correctly without requiring changes.

Adding the super. to place the variable in global scope seems like an easy enough compromise. In most cases it won't be obscure and declaring the variable in the parent scope will be just as easy, which is what you want to do anyway.

Ya, no. Adding super. requires changing the code. The point is that there is a large code base that I can not access to make changes. If I had control over this code base then it would not be an issue. This is not a case of me being lazy or stubborn, I don't see how to solve this problem any other way. If legacy scoping goes away then I cannot use Beanshell 3.0.

[nickl-]

Seems to be a small non-intrusive change, have a look at https://github.com/beanshell/beanshell/issues/727. Could you help me out and explain what I overlooked that makes this more than a small change?

I think you mean #728 Touches 15 files - not a small non-intrusive change, by any standard

The point is that there is a large code base that I can not access to make changes.

If you can't change the code, why change the interpreter? You want to use BeanShell 3.0 because you want to use the new features, right?

If you can change the interpreter, you should be able to change how the interpreter receives the code. Which is only one step away from changing the code, before the interpreter sees it. I'm thinking regex...and you don't have to make changes to the code base.

[opeongo]

Seems to be a small non-intrusive change, have a look at #727. Could you help me out and explain what I overlooked that makes this more than a small change?

I think you mean #728 Touches 15 files - not a small non-intrusive change, by any standard

I think you are using number of files touched as the wrong metric here. The bulk of the lines changed have to do with switching the declared type of the strictJava parameter from boolean to int. The active change is basically a one-liner. But I get it, you are not interested.

The point is that there is a large code base that I can not access to make changes.

If you can't change the code, why change the interpreter? You want to use BeanShell 3.0 because you want to use the new features, right?

Not really. I'm not likely to use many of the new BeanShell 3.0 features and as we have discussed elsewhere I disagree with many of them. I do appreciate the many bugfixes, the infrastructure upgrades (maven and test suites), working with Java9+, varargs, try with resources, enums, multi-line strings and perhaps a few other changes over bsh-2.0b6. I also like working with others in a project rather than just going it alone. Forking off my own version seems like such a big wasteful duplication of resources when there are very few of us working on BeanShell as it is. It seems losing momentum is something that the BeanShell project cannot afford, so I have been hanging in there.

If you can change the interpreter, you should be able to change how the interpreter receives the code. Which is only one step away from changing the code, before the interpreter sees it. I'm thinking regex...and you don't have to make changes to the code base.

So how does this work? I patch my version of BeanShell so that anytime the interpreter reads in code (e.g. source command) it runs through a regex filter? So I will need to maintain my own fork?

[nickl-]

So how does this work? I patch my version of BeanShell so that anytime the interpreter reads in code (e.g. source command) it runs through a regex filter? So I will need to maintain my own fork?

No, use regex to patch the source you "can not access to make changes", on the fly i.o.w. before beanshell receives the source. No mention of maintaining forks.