Opened 13 years ago
Closed 12 years ago
#7127 closed defect (fixed)
Upgrade custom Rhino to 1_7R1
Reported by: | Chris Mitchell | Owned by: | James Burke |
---|---|---|---|
Priority: | high | Milestone: | 1.3 |
Component: | ShrinkSafe | Version: | 1.1.1 |
Keywords: | Cc: | alex | |
Blocked By: | Blocking: |
Description
Dojo 1.1.1 currently uses Rhino 1_6R7. The latest version is 1_7R1. 1_7R1 fixes a licensing issue where some Sun code was pulled into the Rhino binary. It makes it easier for companies who want to redistribute shrinksafe if Dojo 1.2 builds were based on Rhino 1_7R1. Alternatively, we could modify custom_rhino.jar to remove the Sun files from the jar, since they are only used by the Rhino debugger...but this is not the preferred route.
Change History (8)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Actually, they are not "scheduled" to be put back into 1_7R2. There is just a comment that they could potentially be reintroduced into Rhino under the new terms going forward.
comment:3 Changed 12 years ago by
Cc: | alex added |
---|
James has the code ported over to 1.7R1, but it fails in cases where functions are nested several layers deep. I've isolated it to the following test case:
var foo=function(){ function bar(){ // bar should be compressed since it's not global. It is not compressed unless you either change this definition to var bar=function(...) or eliminate the line below... (function(){}); // without a function definition inside bar, the symbol 'bar' compresses properly. Any sort of function definition will do here. } bar(); } foo();
I think the problem may be in
TokenMapper.collectFuncNodes()
. If I run the example below, it does a tree walk, and as it unwinds, the third-level nesting causes the function "bar" to go into the "3" bucket in functionVarMappings; without it, "bar" ends up in the "2" bucket and the code compresses properly.
It makes no sense to my why this would have regressed in Rhino 1.7, but I don't fully understand the tree walk code in
collectFuncNodes
, which I believe is our code. Why does it put the var names in the last bucket when it unwinds (functionVarMappings.size()-1
) This value seems to depend on the depth of the function nesting rather than the relative position of the scope chains.
bindingNames = (HashMap) functionVarMappings .get(functionVarMappings.size() - 1); bindingNames.put(new Integer(level), parseTree .getParamAndVarNames());
when
isInScopeChain
goes to look up 'bar' infunctionVarMappings(functionNum)
wherefunctionNum
is 2 my example, the value is not found unless I remove the third-level nested function.
comment:4 Changed 12 years ago by
I've removed the sun files from custom_rhino.jar (see #7503) in the interim, so if we have to we can defer this ticket to 1.3.
comment:5 Changed 12 years ago by
Milestone: | 1.2 → future |
---|
I have not been able to look at this more since peller isolated the test case. Going to defer for now, but still very interested to get this to work at some point.
comment:6 Changed 12 years ago by
Component: | BuildTools → ShrinkSafe |
---|---|
Owner: | changed from James Burke to alex |
comment:7 Changed 12 years ago by
Owner: | changed from alex to James Burke |
---|
comment:8 Changed 12 years ago by
Milestone: | future → 1.3 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
The details of the issue with Rhino including Sun files are described in the following Rhino bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=419491
The source files of concern are:
AbstractCellEditor?.java JTreeTable.java TreeTableModel?.java TreeTableModelAdapter?.java
which build the following class files in the Rhino binary distribution:
These files have all been removed from the Rhino 1_7R1 release.
Also, as described in the bug above, Sun has released these files under a new license agreement that should be more acceptable to companies redistributing Rhino. So, these files are currently scheduled to be put back into Rhino in the 1_7R2 release, which is currently under development.