Calculate JDK javadoc links dynamically.

[mbien]

Some time in future when aliens find an old NetBeans installation somewhere, at least they will be able to read the newest javadoc.

[neilcsmith-net]

As said on the other PR, I'd rather keep that for NB16 I think, and work on this in master. I'm also wondering whether the date approach is the right one, rather than prepopulating all the ones up to the supported source level in the IDE, and possibly pinging the docs site if a higher JDK is requested?

[mbien]

done. cherry picked on top of master and force pushed.

Regarding the right approach. I don't know. This seems to be working fairly well. I wouldn't do IO in an static analyzer block so this would have to go somewhere else. If someone wants to implement it differently feel free to close this one.

[neilcsmith-net]

Definitely not suggesting IO in the static initalizer. If we can prepopulate the OFFICIAL_JAVADOC map with all the values up to the maximum officially supported by the IDE (we've previously discussed whether we need an API other than SourceVersion.latest() for that), then we could consider polling somewhere about https://github.com/apache/netbeans/blob/master/java/java.j2seplatform/src/org/netbeans/modules/java/j2seplatform/platformdefinition/J2SEPlatformDefaultJavadocImpl.java#L89 ? eg. Map::computeIfAbsent ?

[mbien]

@neilcsmith-net having some version API would be probably useful (NetBeans.version() analog to Runtime.version()), but would it be in this case? Its just a map of currently available javadoc links. NB doesn't necessarily have to support the version in question.

E.g I have a bookmark group in the browser which links to all javadocs between 5 and current/ea so that I can quickly access them if needed.

Wouldn't a "Other OpenJDK docs" submenu be useful too which simply lists everything - no matter what NB version is in use?

(I get that NB is smart and trying to list only the doc for the opened projects, but sometimes this is a bit too smart if you want to quickly look something up)

The Map itself might not be the most elegant way of solving this, but maybe a simple method which does some date math and calculates the link at runtime would do - since its so easy to calculate. But for now I have no memory concerns due to the growing size of the map :P

[neilcsmith-net]

NB doesn't necessarily have to support the version in question.

Yes, that was kind of my point. Anything strictly supported we know is GA, so the links can just be generated in the map in the initializer without reference to the date at all. Anything above supported could be GA or EA. This will only be relevant for registered platforms anyway, I believe? In which case, we could either ping to find the right location, or even just leave blank for the user to set. Isn't the date method most likely to get this wrong around the date of releases? About the time more people might try it.

We could change Javadoc references to list all registered platforms, rather than just ones tied to open projects?

[mbien]

Yes, that was kind of my point. Anything strictly supported we know is GA, so the links can just be generated in the map in the initializer without reference to the date at all.

sure why not. I don't quite see the advantage of having two ways to compute this. But whatever works and doesn't make this simple feature unnecessary complex is fine. I wouldn't add a NBVersion API just for those links given how difficult it is to remove or update APIs again from NetBeans.

We could change Javadoc references to list all registered platforms, rather than just ones tied to open projects?

not sure if this would be better - some might like that they only see doc for what is opened. I was thinking of an extra menu entry which simply shows everything unfiltered. A smart option and an all option. But my bookmark group in the browser works fine too - I don't actually need it myself - it was just an idea.

[pepness]

This PR is ready. Checked today that the JDK 20 and JDK 21 javadocs are correct.
JDK 20

JDK 21

[mbien]

@neilcsmith-net you ok with this?

[mbien]

@pepness thanks for testing and reviewing, I completely forgot about this PR

[neilcsmith-net]

Never let perfect be the enemy of good! If it's working, let's get it in. Can always look at latest supported source level then date as a later change.

[mbien]

@neilcsmith-net awesome! Not sure if I have to do this but going to rebase locally to latest master to get rid of the merge commit which is in this branch before merging.