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.
[ 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 "GenerateCharsetData". For reproduce, you maybe should examine my project: https://java-nio-charset-enhanced.dev.java.net/ (checkout Subversion revision=683; uncomment 'System.out...' in class GenerateCharsetData) Be aware to run from configuration "GenerateCharsetData". A 2nd JDK must be installed (here: JDK 6u03).
You can better checkout Subversion revision=686.
Created attachment 79125 [details] Constant not linked after CoS
This should be already fixed, see issue 158218 *** This issue has been marked as a duplicate of 158218 ***
Actually for verifying issue 158218 I used this test case from this issue (uses byte instead of String constant).
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.
Steps to reproduce: -in an empty directory, execute: svn checkout -r 686 https://java-nio-charset-enhanced.dev.java.net/svn/java-nio-charset-enhanced/trunk -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/System.java from the Source Packages, if necessary, to workaround: https://java-nio-charset-enhanced.dev.java.net/issues/show_bug.cgi?id=2 -add: application.args=make/tools/CharsetMapping SingleByteCharsets.conf resources to: trunk/nbproject/configs/GenerateCharsetsData.properties (revision 686 does not contain this setting!) -open: trunk/make/src/build/tools/charsetmapping/GenerateCharsetsData.java and on line 199 uncomment the debug messages -open: trunk/src/sun/nio/cs/BaseCharset.java -change the value of "MAP_HAS_PARENT" property (line 32), execute the project using F6 - old value is reported.
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. (see https://java-nio-charset-enhanced.dev.java.net/issues/show_bug.cgi?id=1) Did you compile against update 03 of JDK 6? (wondering about the compile error for System.java) 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.
Reproducible, the problem is probably in source roots - when I tried to moved everything under single source root the changes are propagated correctly
Is is possible to fix this into patch1, if it isn't too dangerous? Thanks
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. Sorry.
Honzo, do you plan to work on this or should I re-assign it to someone else?
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 recompiled. The workaround is to switch off Compile on Save. *** This issue has been marked as a duplicate of 147000 ***
To clarify: I experienced the problem inside a single project. See link above from June 9.
Are you experiencing the problem within a single source root?
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.
Additionally I like to remember my statements about "Rethinking CoS again" in NetCAT mailing list from april 15.
And don't forget, the order of opening editor tabs is important here.
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).
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 ***
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.