improved JDK detection startup tasks

[mbien]

• repurposed debian task to support more distributions
• registered JDK names will now receive the (System) or (SDKMAN) postfixes
• only register a JDK if it wasn't registered yet since registering JDKs seems to be expensive (and we don't want to overwrite anything)

[lkishalmi]

I thought that property is used as a platform ID. It is unfortunate that the Platform API does not have an ID. So internally we use that property value as an unofficial ID.

That is being saved in projects metadata if you select the non-default Java platform (in Ant, Maven and Gradle) projects.

Once I was thinking about adding a getId() to the platform, making that official, but then decided not to.

Anyway just felt odd making decisions on Display name.

[lkishalmi]

Next JDK-s to be detected the ones in $HOME/NetBeansJDKs/ and the ones in $HOME/.gradle/jdks...

[mbien]

update: it is now checking installation paths too, in addition to the registered platform name, to not register duplicates or overwrite existing ones.

[mbien]

@lkishalmi what do you think? Should we get this in? It checks now paths + names for conflicts.

[neilcsmith-net]

The namer should really only be applied if that path doesn't already have the file attribute for the name? Otherwise it should be the value of that attribute.

We could do with a better way of linking path and chosen name - the idea was to allow re-registered JDK's to get the previously set user name by default.

It's probably a minor concern now you're checking for path rather than name to determine registration, but could still be worth considering?

[mbien]

The namer should really only be applied if that path doesn't already have the file attribute for the name? Otherwise it should be the value of that attribute.

my thinking was to not mess with already registered JDKs at all if there is a conflict in name or path. If the user changed something, the user should remove it first before the automation kicks in again. Being too smart here by updating things quietly during restarts could cause issues.

Keep in mind the version before that registered JDKs without any checks :)

[mbien]

actually you are probably right. What if SDKMAN is updating JDKs in place. The old version would have simply overwritten the registered platforms. This PR would keep the old ones until they are manually removed.

probably better to think about this more (and I gonna have to install SDKMAN somewhere)

[lkishalmi]

SDK man does not update JDK in place as far as I know. It downloads the new one and sets the current symlink to the one used.

[mbien]

@neilcsmith-net i tested this:

                        String jdkName = null;
                        FileObject fo = FileUtil.toFileObject(jdk);
                        if (fo != null) {
                            Object value = fo.getAttribute("J2SEPlatform.displayName"); // NOI18N
                            if (value instanceof String) {
                                jdkName = (String) value;
                            }
                        }
                        if (jdkName == null) {
                            jdkName = namer.apply(jdk);
                        }

and I believe this is worse since it can lead to very weird behavior. If you add a JDK with a custom name, then remove it again, it will be added with the same name again on next start which looks for the user as if removal didn't work.

Having automated JDK detection use a fixed naming pattern is better IMO, since it automatically communicates where this is from.

@lkishalmi thanks for checking!

[mbien]

interesting idea.

                    FileObject fo = FileUtil.toFileObject(jdk);
                    if (fo != null) {
                        Object value = fo.getAttribute("J2SEPlatform.displayName"); // NOI18N
                        if (value instanceof String) {
                            break; // skip, this indicates that it was added (and potentially removed) by the user
                        }
                    }

i think this has potential but there is one big issue: there is no reset button. We would have to be prepared to tell users to remove nb_userdir/var/attributes.xml

[mbien]

however :)

having to remove this check later is probably the better option than not having it -> going to change it

[neilcsmith-net]

Why is the lack of a reset button an issue? If a JDK registration has been manually removed, shouldn't it need to be manually re-added?

That attribute was added primarily to try and maintain the names given to Disco downloaded JDKs incidentally. So they could be removed and then re-added under same name. I've had doubts since about that way to do it, but somewhere I think we should store metadata like names, removal status, etc. of manually unregistered JDKs.

[mbien]

Why is the lack of a reset button an issue? If a JDK registration has been manually removed, shouldn't it need to be manually re-added?

the longer I thought about it the more I liked the idea of skipping those folders. I think it is the safest option to get auto detection in.

step 1: don't ever override already registered JDKs
step 2: don't annoy the user by registering stuff the user potentially just removed

having a growing "block list" without reset button sounded intuitively wrong to me, but it is probably completely fine in this particular case - and the better option to not having it.

[neilcsmith-net]

It'll also reset on IDE upgrade - those attributes don't get imported (one of the issues with using them for this IMO). I think it would be good to get this in for NB18, then possibly rethink how we store info in NB19, and whether we need a reset.

[lkishalmi]

Just some insights on SDKMAN:

lkishalmi@desktop-su4jobc:~/NetBeansProjects/netbeans$ ls -l ~/.sdkman/candidates/java/
total 19
drwxr-xr-x  9 lkishalmi lkishalmi 11 Jan 18 02:13 17.0.6-tem
drwxr-xr-x 10 lkishalmi lkishalmi 14 Mar  7 00:53 20-zulu
lrwxrwxrwx  1 lkishalmi lkishalmi 10 Apr 15 10:53 current -> 17.0.6-tem