Bug 215698

Note that <version>[1.6,1.7)</version> might have been expected here, but the range as written works, presumably since the actual version is something like 1.6.0-33.

Basically when this plugin is present, and netbeans.hint.jdkPlatform is undefined, the IDE should search through all JavaPlatform's in descending spec version order looking for one which would match the range.

looks more or less ok to me, the only (usual) problematic area is the UI editing of platform. Currently when you select Default Platform, the netbeans.hint.jdkPlatform should disappear, but I've experimentally verified that even now when you place the hint property in the parent pom file, the property gets rewritten in current file as well. even with the "default" value..That would be a bug IMHO.

maybe we should take the source/target parameters of the compiler plugin into account. Eg. cannot use 1.7 default platform if source/target is at 1.8 (but not vice versa)

https://hg.netbeans.org/core-main/rev/abeccec26a77

only enforcer done, no compiler's source/target

If enforcer says [1.7,) but compiler says -source 1.8 then your POM is broken, so I think that case can be ignored.

Not sure exactly what abeccec26a77 is doing, but it seems to be wrong in 20130410-2221abd2426c. I am running the IDE on JDK 7, with some JDK 6 installations defined in Java Platforms. I click Build on Jenkins core and the IDE tries to use one of the JDK 6 installations.

Why was the IDE picking JDK 6 rather than the default platform, JDK 7, when Jenkins builds fine on JDK 7? The effective POM says

<requireJavaVersion>
    <version>1.6.0-18</version>
</requireJavaVersion>

which according to http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html means this version or greater.

My guess is that

Map<ArtifactVersion, JavaPlatform> found = new TreeMap<ArtifactVersion, JavaPlatform>();

should be setting a reverse comparator as in comment #1.

Due to the faulty logic, the change so far is a significant regression from my perspective. Workaround: add to ~/.m2/settings.xml:

<profile>
    <id>netbeans.215698.disable</id>
    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
        <netbeans.hint.jdkPlatform>default_platform</netbeans.hint.jdkPlatform>
    </properties>
</profile>

(Changing the platform back to “JDK 1.7 (Default)” in the Compile panel does not work; the selection is not saved.)

(In reply to comment #6)
> Not sure exactly what abeccec26a77 is doing, but it seems to be wrong in
> 20130410-2221abd2426c. I am running the IDE on JDK 7, with some JDK 6
> installations defined in Java Platforms. I click Build on Jenkins core and the
> IDE tries to use one of the JDK 6 installations.
> 
> Why was the IDE picking JDK 6 rather than the default platform, JDK 7, when
> Jenkins builds fine on JDK 7? The effective POM says
> 
> <requireJavaVersion>
>     <version>1.6.0-18</version>
> </requireJavaVersion>
> 

I'm a bit lost here. Given that the enforcer requires 1.6.0-18, then picking a lowest jdk found is correct IMHO. Using 1.7 or 1.8 could introduce dependencies on classes from that jdk which is unwanted, no?

marking P2 defect so that we don't forget to resolve the issue. Reverting the change is a possibility.

(In reply to comment #8)
> Using 1.7 or 1.8 could introduce dependencies
> on classes from that jdk which is unwanted, no?

No, that is what Animal Sniffer is for. In fact in my case the baseline Java version is 1.5; 1.6+ is required for compilation; @IgnoreJRERequirement allows controlled use of 1.6 APIs. (1.7+ via reflection only; currently it is up to the developer to ensure that a method marked @IJRER can in fact be built and run against 1.6, which is not a big deal since these are rare and you are probably explicitly testing them.)

I guess the analogy would be to (non-boot-)classpath dependencies in some project types like Maven NBM: we put everything applicable on the editor’s classpath, but use build-time errors and/or editor warnings to guard against inappropriate uses of transitive dependencies and the like. Compare bug #170231 comment #16.

My intention with this issue was only to pick a JDK which _can_ be used to build the project, so that the IDE does not blindly try to run Maven using a version which it can predict will be rejected by Enforcer, forcing you to manually configure the JDK. But where Enforcer is not used, or would accept the default JDK, keep on doing that as before. (I guess the default JDK should be preferred to a newer JDK, e.g. 1.8, if both are eligible. This makes the minimum change to 7.3 behavior: the only difference is with projects which previously would not have been buildable at all without an explicit JDK selection.)

Admittedly it is always a matter of policy whether you prefer to run e.g. tests against the earliest supported platform, or against the newest recommended version that the application will probably actually use. My general experience has been that it is more pleasant for the developer to build & run against the newest version which users are most likely to have, with continuous integration used to verify compatibility with earlier and discouraged versions (or when possible to test all combinations). For example, in NetBeans development nbjdk.home has to be set to 1.6 to avoid broken builds, but this is just because the Ant-based build scripts cannot run AS; as bug #107071 notes, actually running on JDK 6 is inconvenient.

https://hg.netbeans.org/core-main/rev/113aec0be086

reverted the changes

Integrated into 'main-golden', will be available in build *201304272301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/113aec0be086
User: Milos Kleint <mkleint@netbeans.org>
Log: #215698 revert of changes

Thanks, verified in 20130430-6273aaecece2.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss