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.
NetBeans correctly adds whatever JDK it's running with to the Java Platforms list, and uses this as the default for new projects. This is useful because people can start developing/running applications in NetBeans without having to configure anything. However, this is bad in the long run because (a) the default JDK can change and (b) others sharing the project may not have the same default JDK. This can lead to builds that you can't completely reproduce and possibly inconsistent behavior. Netbeans should have an unobtrusive warning somewhere that the user should eventually explicitly specify the JDK if the project is "important". Perhaps using the "fix project problems" mechanism.
How about a warning when opening a version controlled project without a JDK explicitly set, since version controlled projects are more likely intended to be shared?
Not to mention, version controlled projects are more likely intended to be able to exactly reproduce a specific version's build.
Makes sense, however I cannot simply add a warning into Broken Project References as many people are using the default platform (they simply do not care about JDK versions). What comes into my mind is to store the default platform version into the project share d properties (remember that the project was created with default platform == JDK 1.8) and when the project is opened in the NB where default platform is smaller than the JDK 1.8 put the warning into the Broken Project References.
That would work if things don't get too complicated, but would NetBeans handle opening an existing, shared project which doesn't have this property yet? Would NetBeans just add the default JDK of the first person who happened to open it after upgrading NetBeans? I could see how some people would not like that. Also, how would NetBeans handle if someone created a project with 1.7 as the default, then shared that project with someone with 1.8? Assuming the project's properties were not automatically updated when the person with 1.8 opened it (since that would give the person with 1.7 the warning), what happens when the person with 1.7 upgrades to 1.8? Would they need to manually change the default JDK property somehow? My reason for liking the "VCS" approach (only warn about use of the default JDK when the project also uses version control) is that I'd guess the people who want to use a version control system for a particular project and the people who don't care what JDK a particular project runs with tend to be (mostly) mutually exclusive. Besides, using a VCS without specifying a JDK is asking for trouble, since the main reasons for using version control is to share a project with others or reproduce a historical build or build component (the project's source/target JDK may change at some point). It also has the advantages of not requiring any project metadata changes or added project settings, assuring the top end of stack traces match when reproducing a build for troubleshooting, and generating identical (in theory) byte code.