Implement ApplicationRestart functions

[matthiasblaesing]

No description provided.

[dblock]

The try block should be around after a successful RegisterApplicationRestart. Then you can combine the UnregisterApplicationRestart call and assertTrue(COMUtils.SUCCEEDED(result)); here so that any errors bubble up.

[matthiasblaesing]

This is not the intention here. UnregisterApplicationRestart is only run in the finally block, so that cleanup happens in any case. The real testing happens inside the the try-block. The real test for UnregisterApplicationRestart is in 1957.

[dblock]

I am possibly nitpicking, so feel free to leave as is. However this is what I am thinking the issues are and generally avoid the practice of doing what you're doing:

• if RegisterApplicationRestart succeeds in 1923, finally calls UnregisterApplicationRestart a second time, which fails silently, which seems like bad practice.
• if RegisterApplicationRestart fails in 1923, finally calls UnregisterApplicationRestart a first time, which fails silently, which seems like bad practice.
• if RegisterApplicationRestart succeeds in 1923, but something else fails, finally calls UnregisterApplicationRestart a first time, which may fail silently, which will leave a registered application restart without anyone noticing, which might potentially cause another subsequent test to fail.

Happy holidays!

[matthiasblaesing]

I'll leave as is. the reasoning is, that this is a unittest not more, not less. The only intention of the finally block is to cleanup as much as possible. It is a last resort - if it works, it will clean up, if if fails, we loose nothing. The functions themselves are tested inside the try-block.

[ebourg]

Is it ok to copy/paste the Microsoft documentation verbatim? I haven't checked thoroughly if they publish it under a license that allows it.

[matthiasblaesing]

My take on this is, that the documentation must be part of the API and I assume API is not copyrightable/this falls under the fair use assumption. I'm not a lawyer and I'm aware, that this is still under discussion in the US.

[dbwiddis]

All the documentation on docs.microsoft.com is open-sourced here and licensed under CC-BY-4.0.

You are free to:

• Share — copy and redistribute the material in any medium or format
• Adapt — remix, transform, and build upon the material
• for any purpose, even commercially.

With only the restriction:

Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

While many of the citations from Microsoft docs (formerly MSDN) were specifically linked in the javadocs (with @see) it's not universal. To make broad API citations more clear, we could add some sort of document in the project root more clearly documenting this usage "in any reasonable manner" (e.g., ASF projects use a NOTICE file for this purpose). The attribution could be an easy one-liner.

[matthiasblaesing]

JNA is not ALv2, it is dual-licensed ALv2+LGPLv2. I don't see a problem: Either the API is copyrightable and this is not fair use, then we can pretty much delete the whole platform project, or it is not copyrightable or fair use, in that case it can stay as is.

[matthiasblaesing]

I updated the new code with references to the MSDN entries - Ok to merge?

[matthiasblaesing]

Hearing no objections I added a note about the requirement, that the JVM must not handle errors itself and will merge on sunday.