Feature/kotlin update

[sghpjuikit]

• update kotlin to 1.3
• add coroutines dependency (will be used in the future)
• use -progressive compiler flag
• use JvmDefault in several interfaces (which also alows converting them to Kotlin)
• minor clean up in relevant classes
• fix nullability issues
• fix relevant compilation warnings

Note:

• contracts for Item.getFile() will be done after the merge (presumably in this branch)

[sghpjuikit]

Another thing, I have set jvmPath to be the the local instance, but that seems to crash the remote build. Any ideas?

[sghpjuikit]

I have tried to use contracts for the getItem() issue, but the result is disappointing.

• contracts can only be used on top level functions (so it requred isFileBased() to be top level extension function)
• contracts are experimental and require weird annotations to suppress warnings all over the place, this makes them virtually impossible to use
• I was unable to avoid the use of getFile()!! after isFIlebased() check.

My attempt

@ExperimentalContracts
fun Item.isFileBased(): Boolean {
    contract {
        returns(true) implies (getFile() is File)
    }
    return "file"==uri.scheme
}

I'm getting 'Only references to parameters allowed in contracts' for using getFile() after implies.

End result: this is very experimental as of now and will have to wait for a while longer.

[xeruf]

I have no idea at all about contracts.

The build seems to try to compile before linking the jdk, if you remove the jdk link locally it will probably fail for the first run as well. I will configure gradle so it runs the jdk linking task first.

Btw, please use triple ``` for multi-line code for readability

[sghpjuikit]

Very good job on cleaning up the build file (it is always educating experience for me to read your changes in this file). However, in the future, please refrain from changing the parts that are of my responsibility - those related to the PR. It is a bad taste. I know you opted for efficiency here and you did save me work, but it was still improper.

[xeruf]

I guessed that, but how else should I do that? Should I make a PR into your PR?

[sghpjuikit]

Not at all, simply leave the parts that you requested of me to change for me.

[xeruf]

But the changes were mostly not things worth explaining, just a few small adjustments. These are things that I can see when I'm editing the file but they maybe wouldn't be apparent to you, but you can understand their purpose just by looking at the diff. So either I commit into the branch (it is good practice anyways to always pull before you start working) or open a PR into the feature-branch.

[sghpjuikit]

You made 2 changes that we were specifically talking about, that's all.

[sghpjuikit]

What is the + notation in the version of the dependendies in the build file? To use latest minor version automatically? If that is the case I disagree with using that feature. Automatic dependency pulling is unpredictable and dangerous. Only developer can raise the version.

[sghpjuikit]

I have also finally figured out why my project start up takes 20-30 seconds sometimes. After you updated the build file and the linkJdk task name is printed. It is the linkJdk task!! It always executes for me when run the project! I finally know this drove me absolutely crazy! Ill look into this as well.

[xeruf]

The linkJdk task name is printed? Huh? What's going on?

Yes the + is for automatically using the latest minor version. I thought about whether or not to put it in, but I thought it might be helpful to not have to update them manually all the time. If you disagree, feel free to revert it.

[sghpjuikit]

No, please remove the +. I understand the advantages, but we are opening up a way for (potentially serious) bugs to worm in. Like XStream update screwing up widget serialization.

I'm not sure about linkJdk, lets handle that in separate issue (if it even is an issue to begin with). It is not running always for me (well it is, but it runs instantly). So far I have only observed it to run a long time once, but that should never happen at all, since my jdk is already linked.

[xeruf]

+ has been removed again

I found the issue with linkJdk: Because of compilation failures I needed to make compileKotlin depend on it, but I didn't properly configure it to communicate to Gradle when it is up to date and does not need to run, so it should be fixed now.

[sghpjuikit]

I understand what you did with linkJdk task (nice), but I dont think it should impact my performance, because it doesnt matter whether gradle runs the isUpToDate check or the task itself - the linking should never occur on my machine, yet it seems it sometimes did. I will observe the behavior with your solution.