It is time to announce [[APIFest08:Report|results of APIFest08]].

It is time to announce [[APIFest08:Report|results of APIFest08]]. Listen to related podcast [[Image:Apitip05-apifest-game.mp3]] or [[Media:Apitip05-apifest-game.mp3|download]] it!

 

The [http://www.netbeans.org/birthday/ celebration of 10 years] of [[NetBeans]] releases is in progress and that is why it is also time to celebrate all those who contributed to the [[NetBeans]] architecture, and design practices which make [[NetBeans]] platform the most stable Java rich client application framework.

The [http://www.netbeans.org/birthday/ celebration of 10 years] of [[NetBeans]] releases is in progress and that is why it is also time to celebrate all those who contributed to the [[NetBeans]] architecture, and design practices which make [[NetBeans]] platform the most stable Java rich client application framework.

All solutions are flawed in one or other way. As such nobody gets '''ten points''' for creating an ''unbreakable'' solution. The only points awarded are only for exploits:

All solutions are flawed in one or other way. As such nobody gets '''ten points''' for creating an ''unbreakable'' solution. The only points awarded are only for exploits:

{{:PetrSmid}}

 

[[Image:PetrSmid.jpg]]

 

==== Jan Žák ====

==== Jan Žák ====

}

}

public boolean canConvert(String s1, String s2) {

public boolean canConvert(String s1, String s2) {

if (keys.contain(s1) && keys.contains(s2)) {

if (keys.contains(s1) && keys.contains(s2)) {

return true;

return true;

}

}

All solutions are flawed in one or other way. As such nobody gets '''ten points''' for creating an ''unbreakable'' solution. The only points awarded are only for exploits:

All solutions are flawed in one or other way. As such nobody gets '''ten points''' for creating an ''unbreakable'' solution. The only points awarded are only for exploits:

Both '''Petr''' and '''Jan''' should stop in Sun's Prague office to get their copy of [[TheAPIBook]]. '''Jan''' is the absolute winner of [[APIFest08]] - he broke four solutions, plus correctly challenged another one. However, I'd like to congratulate you all, dear participants. I enjoyed the game and I hope you are not sorry for participating either.

 

 

 

 

 

 

 

Both '''Petr''' and '''Jan''' [http://honza.smugmug.com/gallery/6413638_sHjLk visited in Sun's Prague office] on Thursday 30, 2008 and got their copy of [[TheAPIBook]]. '''Jan''' is the absolute winner of [[APIFest08]] - he broke four solutions, plus correctly challenged another one. However, I'd like to congratulate you all, dear participants. I enjoyed the game and I hope you are not sorry for participating either.

Thanks, [[User:JaroslavTulach|Jaroslav Tulach]]!

Thanks, [[User:JaroslavTulach|Jaroslav Tulach]]!

<comments/>

<comments/>

When I checked the state of all solutions after [[APIFest08:Task3|task 3]], I found a perfect way to win. The solution 07 is an example of absolute API stability. The author of this solution managed to guess my future requirements and he changed nothing in the original API in first three rounds! Indeed, it is impossible to find an inconsistency in two versions of an API if they are identical. That is why my own goal for [[APIFest08:Task4|task 4]] was to force the author of solution 07 to make some changes. I succeeded, the API version 4 is different than the previous versions, however as the solution 07 is based on a variation of [[APIDesignPatterns:RequestResponse|request/response]] pattern, it still seems unbreakable.

When I checked the state of all solutions after [[APIFest08:Task3|task 3]], I found a perfect way to win. The solution 07 is an example of absolute API stability. The author of this solution managed to guess my future requirements and he changed nothing in the original API in first three rounds! Indeed, it is impossible to find an inconsistency in two versions of an API if they are identical. That is why my own goal for [[APIFest08:Task4|task 4]] was to force the author of solution 07 to make some changes. I succeeded, the API version 4 is different than the previous versions, however as the solution 07 is based on a variation of [[APIDesignPatterns:RequestResponse|request/response]] pattern, it still seems unbreakable.

And actually nobody managed to question [[BackwardCompatibility]] of the solution. But '''Jan Žák''' noticed an important problem. To quote his email: ''Sometimes - like in the Task2 - the author even added nothing to the API and implemented the requested feature directly in the test case. I'm not convinced, that this approach is strictly fair.''. When I look at the quest of the [[APIFest08:Task2]] and see the complex subclassing classing code provided by solution 07...

And actually nobody managed to question [[BackwardCompatibility]] of the solution. But '''Jan Žák''' noticed an important problem. To quote his email: ''Sometimes - like in the Task2 - the author even added nothing to the API and implemented the requested feature directly in the test case. I'm not convinced, that this approach is strictly fair.''. When I look at the quest of the [[APIFest08:Task2|second round]] and see the complex subclassing classing code provided by solution 07...

<source lang="java">

<source lang="java">

/** Merge all currency rates of convertor 1 with convertor 2.

/** Merge all currency rates of convertor 1 with convertor 2.

* Implement this using your API, preferably this method just delegates

* Implement this using your API, preferably this method just delegates

* into some API method which does the actual work, without requiring

* into some API method which does the actual work, without requiring

* API clients to code anything complex.

* API clients to code anything complex.

*/

*/

public static Convertor merge( final Convertor one, final Convertor two ) {

public static Convertor merge( final Convertor one, final Convertor two ) {

// quite a complex code with subclassing

// quite a complex code with subclassing

}

}

</source>

</source>

=== Problems in Solution 07 ===

=== Problems in Solution 07 ===

When I checked the state of all solutions after [[APIFest08:Task3|task 3]], I found a perfect way to win. The solution 07 an example of absolute API stability. The author of this solution managed to guess my future requirements and he changed nothing in the original API in first three rounds! Indeed, it is impossible to find an inconsistency in two versions of an API if they are identical. That is why my own goal for [[APIFest08:Task4|task 4]] was to force the author of solution 07 to make some changes. I succeeded, the API version 4 is different than the previous versions, however as the solution 07 is based on a variation of [[APIDesignPatterns:RequestResponse|request/response]] pattern, it still seems unbreakable.

When I checked the state of all solutions after [[APIFest08:Task3|task 3]], I found a perfect way to win. The solution 07 is an example of absolute API stability. The author of this solution managed to guess my future requirements and he changed nothing in the original API in first three rounds! Indeed, it is impossible to find an inconsistency in two versions of an API if they are identical. That is why my own goal for [[APIFest08:Task4|task 4]] was to force the author of solution 07 to make some changes. I succeeded, the API version 4 is different than the previous versions, however as the solution 07 is based on a variation of [[APIDesignPatterns:RequestResponse|request/response]] pattern, it still seems unbreakable.

And actually nobody managed to question [[BackwardCompatibility]] of the solution. But '''Jan Žák''' noticed an important problem. To quote his email: ''Sometimes - like in the Task2 - the author even added nothing to the API and implemented the requested feature directly in the test case. I'm not convinced, that this approach is strictly fair.''. When I look at the quest of the [[APIFest08:Task2]] and see the complex subclassing classing code provided by solution 07...

And actually nobody managed to question [[BackwardCompatibility]] of the solution. But '''Jan Žák''' noticed an important problem. To quote his email: ''Sometimes - like in the Task2 - the author even added nothing to the API and implemented the requested feature directly in the test case. I'm not convinced, that this approach is strictly fair.''. When I look at the quest of the [[APIFest08:Task2]] and see the complex subclassing classing code provided by solution 07...

The [http://www.netbeans.org/birthday/ celebration of 10 years] of [[NetBeans]] releases is in progress and that is why it is also time to celebrate all those who contributed to the [[NetBeans]] architecture, and design practices which make [[NetBeans]] platform the most stable Java rich client application framework.

The [http://www.netbeans.org/birthday/ celebration of 10 years] of [[NetBeans]] releases is in progress and that is why it is also time to celebrate all those who contributed to the [[NetBeans]] architecture, and design practices which make [[NetBeans]] platform the most stable Java rich client application framework.

Both '''Petr''' and '''Jan''' should stop in Sun's Prague office to get their copy of [[TheAPIBook]]. '''Jan''' is the absolute winner of [[APIFest08]] - he broke four solutions, plus correctly challenged another one. However, I'd like to congratulate you all, dear participants. I enjoyed the game and I hope you are not sorry for participating either.

Both '''Petr''' and '''Jan''' should stop in Sun's Prague office to get their copy of [[TheAPIBook]]. '''Jan''' is the absolute winner of [[APIFest08]] - he broke four solutions, plus correctly challenged another one. However, I'd like to congratulate you all, dear participants. I enjoyed the game and I hope you are not sorry for participating either.

Thanks, [[User:JaroslavTulach]]!

Thanks, [[User:JaroslavTulach|Jaroslav Tulach]]!

<comments/>

<comments/>

== Results ==

== Results ==

All solutions are flawed in one or other way. As such nobody gets '''ten points''' for creating an ''unbreakable'' solution. As such the only points awarded are only for exploits:

All solutions are flawed in one or other way. As such nobody gets '''ten points''' for creating an ''unbreakable'' solution. The only points awarded are only for exploits:

* '''Petr Šmíd''' broke solutions 4, 6, 11, 13.

* '''Petr Šmíd''' broke solutions 4, 6, 11, 13.

* '''Jan Žák''' broke solutions 4, 6, 13, 14 and challenged correctness of solution 7

* '''Jan Žák''' broke solutions 4, 6, 13, 14 and challenged correctness of solution 7

Both '''Petr''' and '''Jan''' should stop in Sun's Prague office to get [[TheAPIBook]]. '''Jan''' is the absolute winner of [[APIFest08]] - he broke four solutions, plus correctly challenged another one. However, I'd like to congratulate you all, dear participants. I enjoyed the game and I hope you are not sorry for participating either.

Both '''Petr''' and '''Jan''' should stop in Sun's Prague office to get their copy of [[TheAPIBook]]. '''Jan''' is the absolute winner of [[APIFest08]] - he broke four solutions, plus correctly challenged another one. However, I'd like to congratulate you all, dear participants. I enjoyed the game and I hope you are not sorry for participating either.

Thanks, [[User:JaroslavTulach]]!

Thanks, [[User:JaroslavTulach]]!

<comments/>

<comments/>

This is the solution provided by '''Petr Šmíd'''. As Petr is one of the last standing hackers, his solution is not easy to break. I managed to exploit [http://source.apidesign.org/hg/apifest08/file/2ae6e4aa7aef/taskx/jtulach/against-solution14/test/apifest/CurrencyTest.java change in implementation classes] by using obj.getClass().getInterfaces() check. This does not require any additional permissions, everyone can do this, however it is not really ''fair''. If this was the only way to break Petr's solution, I would still consider his work unbreakable.

This is the solution provided by '''Petr Šmíd'''. As Petr is one of the last standing hackers, his solution is not easy to break. I managed to exploit [http://source.apidesign.org/hg/apifest08/file/2ae6e4aa7aef/taskx/jtulach/against-solution14/test/apifest/CurrencyTest.java change in implementation classes] by using obj.getClass().getInterfaces() check. This does not require any additional permissions, everyone can do this, however it is not really ''fair''. If this was the only way to break Petr's solution, I would still consider his work unbreakable.

However '''Jan Žák''' created more [http://source.apidesign.org/hg/apifest08/file/621462e58e22/taskx/ked/against-solution14/test/apifest/CurrencyTest.java intrinsic exploit] that generates ''ArrayStoreException'', if executed with newer version of the API. The reason for that is that the ''task4'' version wraps all ''CurrencyRate'' with own ''TimeLimitedCurrencyRate'' objects. As these objects are not used only internally, but also exposed to clients with a getter ''getCurrencyRates''. Then it is enough to pass in own objects and check that the returned values are of the same type. Excellent work Jan!

However '''Jan Žák''' created more [http://source.apidesign.org/hg/apifest08/file/621462e58e22/taskx/ked/against-solution14/test/apifest/CurrencyTest.java intrinsic exploit] that generates ''ArrayStoreException'', if executed with newer version of the API. The reason for that is that the ''task4'' version wraps all ''CurrencyRate'' with own ''TimeLimitedCurrencyRate'' objects. As these objects are not used only internally, but also exposed to clients with a getter ''getCurrencyRates'', it is enough to pass in own objects and check that the returned values are of the same type. Excellent work Jan!

The lesson to remember is to [[Separate APIs for Clients and Providers]] as advocated in [[Separate APIs for Clients and Providers|Chapter 8]].

The lesson to remember is to [[Separate APIs for Clients and Providers]] as advocated in [[Separate APIs for Clients and Providers|Chapter 8]].