Allow implementations do initialisation additions

[KostyaSha]

@jglick is there any blocker to make it non-final?
super.init() is not final but this override blocks ability to make aditional initialisations right after job was moved and has new parent, name.

---

This change is 

[oleg-nenashev]

lgtm, I do not see specific reason to prohibit overrides. It would be great to have a @CallSuper annotation, but there is no such annotation in Java

[KostyaSha]

It's also interesting that it possible to call doSetName() but there is no method to set parent in AbstractItem from child classes.

[KostyaSha]

@jglick CC according to history you introduced final

[fcojfernandez]

Hi @KostyaSha. I neither do see any specific reason to avoid the override, but since this final statement has been there since 3 years ago and nothing seems to be failing, I would like to have more details about the motivation/concerns before merging anything.

[KostyaSha]

@fcojfernandez in last 3 years nobody were making any implementations based on folders, since multibranch api become wider used, custom implementations must have ability to do initialisation of their own stuff.

I would like to have more details about the motivation/concerns before merging anything.

I need to do custom things before multibranch starts. That's why upper hierarchy had no final statements. That's look like @jglick mistakenly locked it.

[fcojfernandez]

But in your custom implementation you could initialise their own stuff in the constructor, since you should create one.

(Sorry if I seem picky, but I like having all the details and context to be sure the change makes sense and is safe)

[KostyaSha]

initialisations right after job was moved and has new parent, name.

Move doesn't call constructor, move calls onLoad()

[KostyaSha]

com.cloudbees.hudson.plugins.folder.AbstractFolder#onLoad

[jglick]

It would be great to have a @CallSuper annotation, but there is no such annotation in Java

javax.annotation.OverridingMethodsMustInvokeSuper