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 156231 - Automatic JDK selection from project source level
Summary: Automatic JDK selection from project source level
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 4 votes (vote)
Assignee: Tomas Zezula
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-02 18:41 UTC by _ wadechandler
Modified: 2011-08-31 14:08 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ wadechandler 2009-01-02 18:41:14 UTC
Currently, when working in a Java project in the IDE, one has to select a specific JDK instance by name to work with
Java projects. This affects SE, EE, NB RCP, and even ME I suppose, but maybe not as much. This is problematic in many
instances. The developer has to setup the Java platform and then make sure the name is the same. This is hard to keep
synchronized at times, and version numbers don't necessarily matter as much as the capability to produce 1.5, 1.6, 1.4,
etc output and use those type sources. 

The current method could be kept, and another method added to augment it where the user just sets up a Java platform of
a particular version, and then the IDE determines the best platform to use for a particular project based on the source
selection and a new project property used to limit the versions allowed for the project. Two things, 1) The source level
selection narrows the platform results down to those matching that version or one which can at least support it. 2) a
version limiting mechanism could be used which works like -version:release from:
http://java.sun.com/javase/6/docs/technotes/tools/windows/java.html

That would make things much more dynamic and easier to work with teams. I'll add use cases as other comments.
Comment 1 _ wadechandler 2009-01-02 19:06:21 UTC
Below are the use cases. Basically this helps get around having to setup the same JDK twice named different things, and
makes it faster to work in the IDE or get going rather with other projects etc. I personally have a couple projects I
work on which require me to have differently named JDKs for the same version. I don't know what impact that has if any,
but it is just more to manage for no real gain for me the user.

Use Case - A new project has no named JDK set, has source level/version set, and no limit on the version of the JDK to use

1) The user creates a project
2) The user chooses to not use a named JDK library on the library panel of their project
3) The user sets the project source level to 1.5
4) The default JDK is a 1.6, so this is used for now with no error message or bell to tell the user they need to address
some issue (maybe a hint could be provided)
5) The user adds a 1.5 JDK of a particular update number such as 1.5u13, 14, 15
6) The IDE uses the 1.5 JDK for this project from now on.
7) Other team developers just have to have a workable JDK.

Use Case - A new project has no named JDK set, has source level/version set, and *has* a limit on the version of the JDK
to use

1) The user creates a project
2) The user chooses to not use a named JDK library on the library panel of their project
3) The user sets the project source level to 1.5
4) The user chooses or configures a version limit which only allows some 1.5 JDK (no 1.4 or 1.6) (should be editable in
a textfield and some simple ones generated from the current JDKs available from a drop down)
5) The default JDK is a 1.6, so the user sees an error message on their project that tells them they need to
specifically setup a 1.5 version of the JDK matching the limit.
6) The user adds a 1.5 JDK of a particular update number such as 1.5u13, 14, 15
7) The IDE uses the 1.5 JDK for this project, the project is usable, as it was disabled before, and the error goes away.
8) Other team developers must have a JDK within the limit, and see the error until they do.

Use Case - An existing project has a named JDK set, has source level/version set, and is changed to use automatic JDK
selection

1) The user opens an existing project
2) The user chooses to not use a named JDK library on the library panel of their project.
3) The source level remains the same.
4) The user already has a matching JDK setup by name, so this should have no negative effect on them unless they had
hidden dangers in the form of a lower source level yet newer classes and methods used in which case they see some errors
in their project. The IDE locates the JDK they had set or possibly one better matching their specification to use.
5) Current developers are affected the same way as the person who changed the project when they get it out of source
control, or at least they should be.
6) New project developers should find it easier to setup and use the project.

Use Case - An existing project uses automatic JDK detection, has source level/version set, and is changed to use a named JDK

1) The user opens an existing project
2) The user chooses to use a named JDK library on the library panel of their project.
3) The source level remains the same.
4) As the user chose a named JDK, the version requirements can be ignored (maybe this needs more thought)
5) Current and new developers will have to make sure they have a matching named JDK.
Comment 2 err 2010-03-24 18:06:59 UTC
I think a key point would be to provide a warning if the jdk being used for compiling does not match the source level.

There should be warnings indicated at least at *both*
  - ProjectProperties > Sources > Source/Binary Format
  - ProjectProperties > Libraries > JavaPlatform
The relatively new validate coupled with badges would sure be nice.
Comment 3 err 2010-03-24 18:11:57 UTC
I just reread the title of this issue and comment #2 does not really belong here. Is it worth filing an enhancement request?