Hi,
given the context I assume we are talking about ant projects.
to be sure I understand the problem: do 300 sample/lecture
ant projects need to increase their language level periodically? I feel this is
relatively
easy to achieve with a script which updates javac.source and javac.target every
semester.
If the ant projects use the default JDK, they could delegate the source/target
values like:
javac.source=${default.javac.target}
javac.target=${default.javac.target}
When set via project.properties, this would set the values to the JDK version
of the ant
process.
In practice, leaving the language level undefined would be essentially a broken
build.
Maven 4 for example would fail the build (and give some tips how to fix it)
while
maven 3 would attempt building with java 8 language level which would usually
lead to a failure too (but can be more confusing).
NB is essentially just running the build as defined by the project, IDEs filling
in missing config values is something the java ecosystem tried hard to avoid
otherwise it would have created "works on my IDE" situations everywhere.
Builds in CLI and the IDE should produce the same results. If the former fails
the latter
should too (while giving hopefully useful tips how to fix the build if
possible).
best regards,
michael
On 4/28/25 17:02, Bruce Haddon wrote:
> The source/binary/format field in the "Sources" category in a project's
> properties
> designates the version of the JDK needed for the project.
>
> When a version of the installed JDK is changed to another (later) version
> (and the
> at-the-time current version removed), then it becomes necessary to update for
> each project the value of this field to the later JDK.
>
> I am sure that this task is performed by many developers many times. (E.g., as
> a College instructor, I have over 300 projects, many of which my students
> import,
> and they (as well as myself) are usually using the latest JDK version.
>
> My suggestion is that if this field is empty (or perhaps contains a tag such
> as
> "<JDK>") that the version of the JDK given by the environment variable
> "JDK_HOME" be taken as the needed value (or perhaps better or at least, if the
> "JDK_HOME" is absent or indicates a version that is not installed, that the
> version of the JDK being used by the NetBeans application at the time of
> compilation, as that version is guaranteed to be present).
>
> This would enable large collections of projects to be updated by a single
> action, while still not limiting the use of this field to designate a
> specific JDK
> version.
>
> The number of unintended dependencies in the project collection is always very
> few (e.g., some method becoming deprecated), and more easily corrected than
> having to change the source/binary/format field for every project.
>
> Thank you for your attention.
>
>
> ________________________________
> Dr. Bruce K. Haddon
> 1506 Chambers Drive
> +1 303/499 6240
> Boulder, CO 80305-7002
> bruce.had...@colorado.edu<mailto:bruce.had...@colorado.edu>
>
> "Science is facts; just as houses are made of stones, so is science made of
> facts; but a pile of stones is not a house and a collection of facts is not
> necessarily science."-Henri Poincare
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
