You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Mark Brouwer (JIRA)" <ji...@apache.org> on 2007/01/13 17:36:27 UTC
[jira] Created: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
com.sun.jini.tool.ClassDep should be smarter with outer classes
---------------------------------------------------------------
Key: RIVER-7
URL: https://issues.apache.org/jira/browse/RIVER-7
Project: Apache River
Issue Type: Improvement
Reporter: Mark Brouwer
The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
{noformat:nopanel}
class Proxy {
static final class ConstrainableProxy extends Proxy {
}
}
{noformat}
During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-7:
-----------------------------
Attachment: (was: RIVER-7-8-78-151.patch)
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-7:
-----------------------------
Fix Version/s: AR2
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464713 ]
Mark Brouwer commented on RIVER-7:
----------------------------------
The check to perform is rather trivial, with this minor fix the new semantics for {{ClassDep}} will become:
"??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored *(except when the static nested class extends its outer class)*, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??"
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: Apache River
> Issue Type: Improvement
> Reporter: Mark Brouwer
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone closed RIVER-7.
-------------------------------
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
> Attachments: RIVER-7-8-78-151.patch
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-7:
-----------------------------
Attachment: RIVER-7-8-78-151.patch
Fixes issues RIVER-7, RIVER-8, RIVER-78 and RIVER-151 and replaces the earlier patch that has been withdrawn.
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
> Attachments: RIVER-7-8-78-151.patch
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-7:
-----------------------------
Attachment: RIVER-7-8-78-151.patch
Patch for RIVER-7, RIVER-8, RIVER-78 and RIVER-151.
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
> Attachments: RIVER-7-8-78-151.patch
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576299#action_12576299 ]
Mark Brouwer commented on RIVER-7:
----------------------------------
Patch has been withdrawn as I noticed that the latest modifications as response to Bob's remark seem to have resulted in a failure related to the fix for RIVER-8 which my eye didn't caught in earlier tests of the working of {{ClassDep}}.
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer resolved RIVER-7.
------------------------------
Resolution: Fixed
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
> Fix For: AR2
>
> Attachments: RIVER-7-8-78-151.patch
>
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer updated RIVER-7:
-----------------------------
Component/s: com_sun_jini_tool
Affects Version/s: jtsk_2.1
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Components: com_sun_jini_tool
> Affects Versions: jtsk_2.1
> Reporter: Mark Brouwer
> Assignee: Mark Brouwer
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Brouwer reassigned RIVER-7:
--------------------------------
Assignee: Mark Brouwer
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Reporter: Mark Brouwer
> Assigned To: Mark Brouwer
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (RIVER-7) com.sun.jini.tool.ClassDep should be
smarter with outer classes
Posted by "Mark Brouwer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on RIVER-7 started by Mark Brouwer.
> com.sun.jini.tool.ClassDep should be smarter with outer classes
> ---------------------------------------------------------------
>
> Key: RIVER-7
> URL: https://issues.apache.org/jira/browse/RIVER-7
> Project: River
> Issue Type: Improvement
> Reporter: Mark Brouwer
> Assigned To: Mark Brouwer
>
> The javadoc for {{com.sun.jini.tool.ClassDep}} states the following "??By default, if a static nested class is included in the dependency graph, all references from that static nested class to its immediate lexically enclosing class are ignored, to avoid inadvertent inclusion of the enclosing class. (The default is chosen this way because the compiled class file of a static nested class always contains a reference to the immediate lexically enclosing class.) This option causes all such references to be considered rather than ignored. Note that this option is needed very infrequently.??".
> I agree with this default behavior, however I've been surpised a few times by the following use case which always looked like a bug in {{ClassDep}}.
> {noformat:nopanel}
> class Proxy {
> static final class ConstrainableProxy extends Proxy {
> }
> }
> {noformat}
> During dependency checking I want to specify {{Proxy$ConstrainableProxy}} but in most cases this causes {{Proxy}} to be missing from the download JAR file (although often a trust verifier drags it in anyway) and changing the default behavior is not what I want.
> Maybe it is possible to add a check to see whether the enclosing class is a parent of the nested class, if so it could be including in the collection of classes to be considered for dependency checking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.