This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 59008 - ClassNotFound exception - Cannot invoke Encapsulate field hint
Summary: ClassNotFound exception - Cannot invoke Encapsulate field hint
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: REGRESSION
Depends on:
Blocks: 54123
  Show dependency tree
 
Reported: 2005-05-18 09:37 UTC by Tomas Hurka
Modified: 2008-12-23 08:38 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Testcase (patch) that shows the problem. (4.26 KB, patch)
2005-05-18 17:36 UTC, Jan Lahoda
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Hurka 2005-05-18 09:37:07 UTC
Steps:
1) build and install all-java/hints module.
2) open Java source file.
3) Put cursor on line with public field
4) Invoke 'Encapsulate field a - ' hint
5) CNF is thrown
Comment 1 Tomas Hurka 2005-05-18 09:41:14 UTC
This a regression caused by integration of issue #54123.
Comment 2 Jesse Glick 2005-05-18 17:07:12 UTC
Not a core problem. Modules are responsible for declaring their dependencies
correctly. Track down which module is attempting to use a package which is
forbidden to it, and fix the problem. (I cannot offer any better suggestion
without a stack trace.)
Comment 3 Jan Lahoda 2005-05-18 17:35:49 UTC
As far as I know, the problem is that:
1. the refactoring module declares public packages for friends (Java hints is
not a friend for refactoring module).
2. the Java hints module declares implementation dependency on the refactoring
module.
3. the Java hints module is not granted the access to classes from the
refactoring module in spite of it declares the implementation dependency.

I suppose that the implementation dependecy should allow unrestricted access to
all module's classes.

I am attaching a test case the shows the problem.
Comment 4 Jan Lahoda 2005-05-18 17:36:45 UTC
Created attachment 22187 [details]
Testcase (patch) that shows the problem.
Comment 5 Jesse Glick 2005-05-18 18:58:25 UTC
I guess Yarda's patch for issue #54123 was wrong then. It would incorrectly
refuse access in the case that a module with an impl dep on a module with friend
packages tried to access one of those friend packages without being a friend.
Easy to correct though.

Nonetheless please fix the java/hints -> refactoring dep to use normal friend
access, not impl deps.
Comment 6 Jesse Glick 2005-05-19 00:54:23 UTC
Should be fixed now. BTW thanks Jan for the test.

committed   * Up-To-Date  1.66       
core/src/org/netbeans/core/modules/ModuleManager.java
committed   * Up-To-Date  1.42       
core/test/unit/src/org/netbeans/core/modules/ModuleManagerTest.java
committed   * Up-To-Date  1.27       
core/test/unit/src/org/netbeans/core/modules/build.xml
added       * Up-To-Date  1.1        
core/test/unit/src/org/netbeans/core/modules/jars/uses-api-impl-dep-for-friends.mf
Comment 7 Jaroslav Tulach 2005-05-19 09:23:19 UTC
Thanks for fixing this so quickly that I really could not do it sooner. 
Comment 8 Jesse Glick 2005-05-19 15:44:21 UTC
Oh no problem. It was actually pretty easy with the test already written. :-)
Can someone verify that it is working correctly for java/hints?
Comment 9 Tomas Hurka 2005-05-19 16:01:15 UTC
Verified.