198208 - Removal of deprecated in 1.5R4 classes

Status: VERIFIED FIXED

(Rhino Graveyard :: Core, enhancement)

Description

[Igor Bukanov]

I suggest to remove deprecated in 1.5R4 omj.ClassOutput and omj.SecuritySupport
since ClassOutput is not supposed to be used since 1.5R3 and I would prefer that
code using SecuritySupport would be upgraded to use
ClassShutter/SecurityController sooner then later.

Comment 1

[Igor Bukanov]

Attachment: Removal of SecuritySupport and ClassOutput and corresponding setter/getter methods in Context and ClassNameHelper

Comment 2

[Igor Bukanov]

Attachment: Patch update to remove deprecated access methods in Context that simply redirect to corresponding ClassNameHelper methods

Comment 3

[Igor Bukanov]

I commited the patch part that deals with removal of the deprecated
omj.SecuritySupport.

Comment 4

[Igor Bukanov]

Attachment: Patch update to reflect commited removal of SecuritySupport.

Comment 5

[Phil Schwartau]

Verifying checkin in Comment #3 removing |SecuritySupport|:

1. CVS-removal of the file SecuritySupport.java
2. Removal from the file Context.java of references to |SecuritySupport|

Comment 6

[Igor Bukanov]

I committed the above patch so now omj.Context does not depend on
ClassNameHelper. In fact, now only optimizer package depends on
omj.ClassNameHelper and omj.ClassRepository and this classes are not useful on
its own and perhaps they can be moved to optimizer package to reduce code size
when Rhino embedding does not need optimizer? But this is for another bugzilla
report.

Comment 7

[Phil Schwartau]

Trying to verify the checkin, but it seems to contain additional
elements from the patch. For example, in bonsai, the differences
between v1.17 and v1.16 of ClassNameHelper.java shows this change:

WAS THIS:
----------------------------  v.1.16  ----------------------------
public String getTargetClassFileName() {                                
    ClassRepository repository = getClassRepository();
    if (repository instanceof FileClassRepository) {
        return ((FileClassRepository)repository).
            getTargetClassFileName(getClassName());
    }                                                                       
    return null;                                                            
}


NOW THIS:
----------------------------  v.1.17  ----------------------------
public abstract String getTargetClassFileName();     



but I can't see that change in the patch. Is that correct?

Comment 8

[Igor Bukanov]

I should be more careful next time not to infect my commits related to a
particular patch with other changes. 

That 
public String getTargetClassFileName() {...}
is replaced by 
public abstract String getTargetClassFileName();
and its code is moved to optimizer/OptClassNameHelper.java since the only way to
access ClassNameHelper is through OptClassNameHelper instances. In this way
applications that do not use optimizer will have less code.

Comment 9

[Phil Schwartau]

Igor: thanks; marking Verified -

Comment 10

[Igor Bukanov]

Targeting as resolved against 1.5R5