mbien commented on code in PR #6213:
URL: https://github.com/apache/netbeans/pull/6213#discussion_r1266742472
##########
java/java.j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/J2SEPlatformDefaultJavadocImpl.java:
##########
@@ -116,6 +76,35 @@ public Collection<URI> getDefaultJavadoc(@NonNull final
JavaPlatform platform) {
return Collections.emptyList();
}
+ private static String computeJavaDocURL(String version) {
+ switch (version) {
+ case "1.0": // NOI18N
+ case "1.1": // NOI18N
+ case "1.2": // NOI18N
+ case "1.3": // NOI18N
+ case "1.4": return null; // NOI18N
+ case "1.5": return
"https://docs.oracle.com/javase/1.5.0/docs/api/";; // NOI18N
+ case "1.6": return "https://docs.oracle.com/javase/6/docs/api/";;
// NOI18N
+ case "1.7": return "https://docs.oracle.com/javase/7/docs/api/";;
// NOI18N
+ case "1.8": return "https://docs.oracle.com/javase/8/docs/api/";;
// NOI18N
+ }
+ try {
+ int feature = Integer.parseInt(version);
+ if (feature >= 9) {
+ // timezone shouldn't matter since the accuracy is worse than
a day
+ LocalDate jdk9 = LocalDate.of(2017, Month.SEPTEMBER, 21); //
start of 6 month schedule
+ long max = ChronoUnit.MONTHS.between(jdk9, LocalDate.now()) /
6 + 9;
Review Comment:
1) what we know is that we don#t want to bump a number every release - thats
how this all started, we already have to do that for the nb-javac lib, and we
forget it literally every single time like in the current PR #6206 where I
suspect that nobody will notice it until I point it out again :)
2) I think it is worse to compute the max known JDK version out of the NB
version and probe the rest. Thats actually how I wanted to compute
https://github.com/apache/netbeans/blob/8df65b70ed0d17f0e641b961b0ede8ef89ba640d/java/java.source.base/src/org/netbeans/modules/java/source/NoJavacHelper.java#L37
at first.
it has several issues. Results are not stable, they will depend on how well
your wifi was when you start NB which will lead to "doc link missing -> can't
reproduce" issues. It does also link two release schedules together. Taking one
schedule and compute a value seems to be less complicated/direct approach.
The proper way in my opinion would be to ask the JDK what it is. If its EA
it should produce an EA link, otherwise GA. This is also difficult to achieve
since distributions don't use the same version scheme. This whole thing is a
"best effort" approach anyway since the links never accounted for panama/loom
builds etc and simply linked the wrong doc - same with JavaFX I suppose. Also:
EA JDKs will receive GA doc if you are patient enough.
But if you really, really don't want the schedule approach, I would simply
take the runtime version, use it as max known GA version and probe the rest (I
hate pinging things since it introduces unpredictable latency into otherwise
fast returning methods). Which is unstable, but doesn't link two schedules at
least. I also don't want to access Runtime.version via reflection yet again
tbh, I feel like every second module has to do this by now :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
