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 161564 - [67cat] Constant not linked after CoS
Summary: [67cat] Constant not linked after CoS
Status: RESOLVED DUPLICATE of bug 147000
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Jan Lahoda
Depends on:
Reported: 2009-03-31 11:04 UTC by ulfzibis
Modified: 2009-07-23 10:58 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Constant not linked after CoS (105.92 KB, image/jpeg)
2009-03-31 11:19 UTC, ulfzibis

Note You need to log in before you can comment on or make changes to this bug.
Description ulfzibis 2009-03-31 11:04:51 UTC
[ BUILD # : 6.5 Hotfix 3 ]
[ JDK VERSION : 1.6.* ]

I have modified value of static final byte constant in class
"BaseCharset" from 0x10 to 0x20 (see attachment).
After save (CoS enabled) I have run class "GenerateCharsetData".
As you see in the output, old value was linked to class

For reproduce, you maybe should examine my project:
(checkout Subversion revision=683; uncomment 'System.out...' in class
Be aware to run from configuration "GenerateCharsetData".
A 2nd JDK must be installed (here: JDK 6u03).
Comment 1 ulfzibis 2009-03-31 11:18:40 UTC
You can better checkout Subversion revision=686.
Comment 2 ulfzibis 2009-03-31 11:19:46 UTC
Created attachment 79125 [details]
Constant not linked after CoS
Comment 3 Jiri Prox 2009-03-31 11:24:29 UTC
This should be already fixed, see issue 158218

*** This issue has been marked as a duplicate of 158218 ***
Comment 4 ulfzibis 2009-06-06 11:29:35 UTC
Actually for verifying issue 158218 I used this test case from this issue (uses byte instead of String constant).
Comment 5 Jan Lahoda 2009-06-07 10:49:36 UTC
I was able to reproduce the issue in a recent 6.7 build, after adjusting the steps to reproduce non-trivially (I will
add corrected steps to reproduce later). What is not clear to me is why both this bug and issue #158218 were reopen.
Either #158218 is not fixed, and this is a duplicate of it (which does not seem probable), or this is not a dupe of
issue #158218, and the issue #158218 is missing a reproducible test case. ulfzibis, could you please clarify? Thanks.
Comment 6 Jan Lahoda 2009-06-08 09:08:55 UTC
Steps to reproduce:
-in an empty directory, execute:
svn checkout -r 686
-open the "trunk" project in the IDE
-Go to Project Properties/Libraries and change the JDK to a valid JDK6 platform
-change the project configuration to GenerateCharsetsData
-ensure CoS is enabled
-delete java/lang/ from the Source Packages, if necessary, to workaround:
application.args=make/tools/CharsetMapping SingleByteCharsets.conf resources
(revision 686 does not contain this setting!)
and on line 199 uncomment the debug messages
-change the value of "MAP_HAS_PARENT" property (line 32), execute the project using F6 - old value is reported.
Comment 7 ulfzibis 2009-06-09 15:19:57 UTC
Sorry for the delay, and for your time to reproduce.

I didn't note, that now revision 711 is best for NB 6.5, and rev. 713 is updated for 6.7.
Did you compile against update 03 of JDK 6? (wondering about the compile error for

I reopened this issue, to make attention on that I have actually processed issue 158218 by using the byte constant from
this existing project. I first reopened issue 158218 and "translated" the steps for reproduce using a string constant,
which I never tested. Later I thought, it is more accurate, to refer to the test case I actually used, but the regarding
issue was closed as duplicate.
I guess, trying the issue with string constant would fail too (order of opening editor tabs is important, as it invokes
internal compile scan), so both are duplicate of each other.
Comment 8 Jiri Prox 2009-06-10 13:03:22 UTC

the problem is probably in source roots - when I tried to moved everything under single source root the changes are
propagated correctly
Comment 9 Jiri Prox 2009-06-24 16:04:24 UTC
Is is possible to fix this into patch1, if it isn't too dangerous?

Comment 10 David Strupl 2009-07-03 12:08:05 UTC
As we don't have a fix I am removing the patch candidate status for this issue. It will have to wait at least until 6.8.
Comment 11 David Strupl 2009-07-20 16:11:19 UTC
Honzo, do you plan to work on this or should I re-assign it to someone else?
Comment 12 Dusan Balek 2009-07-22 12:49:32 UTC
Yes, this is a problem in Compile on Save mechanism: any file modification in a project causes recompilation of
dependent files within the same project (source root) only! Dependent files from other projects (source roots) are not
The workaround is to switch off Compile on Save.

*** This issue has been marked as a duplicate of 147000 ***
Comment 13 ulfzibis 2009-07-22 16:06:09 UTC
To clarify:
I experienced the problem inside a single project. See link above from June 9.
Comment 14 Dusan Balek 2009-07-22 16:34:28 UTC
Are you experiencing the problem within a single source root?
Comment 15 ulfzibis 2009-07-22 16:56:50 UTC
Do you mean? :
"any file modification in a project causes recompilation of dependent files within the same source root only! Dependent
files from other source roots are not recompiled, regardless if in same or different project."
I'm not sure about what is a "single source root", so please refer to my given project.

I disagree this issue as duplicate from issue 147000.
147000 is about missing error badges in case of broken code, but here I don't miss error badges, as no code is broken.
Comment 16 ulfzibis 2009-07-22 17:05:36 UTC
Additionally I like to remember my statements about "Rethinking CoS again" in NetCAT mailing list from april 15.
Comment 17 ulfzibis 2009-07-22 17:07:51 UTC
And don't forget, the order of opening editor tabs is important here.
Comment 18 Jan Lahoda 2009-07-22 22:00:55 UTC
A few comments:
-there are no "projects" from the (Java) language infrastructure point of view. There are only source roots (folders
containing the source files, elements of source path), classpaths, etc. Your project has several source roots - the
folders containing the sources and the source root containing the tests.
-re "I disagree this issue as duplicate from issue 147000. 147000 is about missing error badges in case of broken code,
but here I don't miss error badges, as no code is broken.": One (root) problem can have several manifestations in the UI
and two distinct (root) problems can have very similar UI manifestations (cf. this issue and #158218). In this case, I
am pretty sure that this issue and issue #147000 have currently the same root cause (this issue is actually combination
of #158218 and #147000, but #158218 is fixed).
Comment 19 Dusan Balek 2009-07-23 09:43:08 UTC
This issue has the same root cause with #147000. (BTW: I have changed the summary description of #147000 to be more
accurate in describing the root cause of the problem).

*** This issue has been marked as a duplicate of 147000 ***
Comment 20 ulfzibis 2009-07-23 10:58:29 UTC
I would say like this:
Before your renaming we had 3 issues (_determined_ by there summary description),
.. where #158218 could be seen as duplicate of #161564 but could be fixed first, as only 1 of the 2 roots for #161564
came to account.
.. #161564 was dependent on 2 roots, one fixed, and one not.
IMHO at this point #161564 was separate issue from summary description point of view, and it's fix was blocked by fix
for 2 other issues.
Why not using established dependency tree here? Instead of redefining #147000.

BTW: #147000 has 2-step dimension, and this issue would be solved, if only 1. dimension of #147000 would be solved.