Blogs:JaroslavTulach:Practical Design
From APIDesign
Practical Design
Introducing Knockout4Java
Knockout4Java takes the best of two words: The type safety of Java and Knockout.js ability to alter any HTML page in any browser. Write your models in Java (using JSON4Brwsr library) and render them as HTML with the help of Knockout4Java!
--JaroslavTulach 21:32, 16 May 2013 (UTC)
Introducing FXBrwsr
FXBrwsr is an attempt to give people the rendering power of HTML (via Knockout.js) and the benefits of HotSpot Java VM. As the Twitter example shows, it is then easy to deploy the application to run Bck2Brwsr.
--JaroslavTulach 09:25, 30 April 2013 (UTC)
Javadoc for Coding for Your Browser Published!
I've just set a job up to generate Bck2BrwsrJavadoc. Anyone wants to design a library for the browser?
--JaroslavTulach 09:11, 1 March 2013 (UTC)
C++ May Not Be As Bad As Thought!
Do you remember my recent post about object oriented encapsulation and performance? It was written in a response to an article that claimed C is much better than C++. There in given example nicely illustrates that by giving up on encapsulation one can implement more effective linked list. In my recent post I managed to prove that by using traits, one can easily get the same performance while keeping encapsulation in modern object oriented language. Only one question remained: Can one do the same with C++ templates?
I am glad to report we have an answer with a sample code. There is a way to write generic template (well two of them) and orchestrate them in a way that keeps encapsulation and maintains the C linked list performance. C++ is not as bad as I thought.
Last note related to this incident (influenced by book I am currently reading). There are tons of comments attached to the original article yet most of them are really shallow. Usually along the line of that is a non-sense!, use STL! or C rules, I knew it!. I guess this has something to do with Thinking, Fast and Slow: people were provoked to react instantly by seeing a topic they had already have an opinion about. Without really giving the issue a though, they replied using fast thinking.
It took me a weekend to come up with the trait solution and we needed about a week to polish the C++ sample code. Looks like a little bit of slowness can worth tons of fast made opinions. But that is for another story - first of all I need to finish reading Thinking, Fast and Slow book.
--JaroslavTulach 07:40, 27 September 2012 (UTC)
Is C Better than C++? Scala Rules!
Recently I've noticed an interesting article describing why C is more effective than C++ and in general most of OOP languages. The article is well written and for a while I was nodding in an agreement. The claim that by using OOP and insisting on encapsulation one cannot implement linked list as effectively as in C is a very good one!
However later I realized that the take on OOP is really targeted to OOP languages of the past. In modern languages, like Scala, one can keep encapsulation and still be as effective as the old plain good C.
All you need is proper orchestration between the List container and its elements. Scala will then type-safely handle the rest for you!
--JaroslavTulach 05:11, 3 September 2012 (UTC)
Why I Became an API Designer?
Why did I decide to be an API Designer with a strong emphasis on BackwardCompatibility?
I've been working on the NetBeans project since middle of nineties. One day, I guess in a year 1999, a product manager stopped by and started to shout at me:"We need partners, we need people to code plugins for NetBeans. We need compatibility. Are we compatible or not?" I started to explain we are compatible - just a few methods and classes were renamed, deleted, but nobody was supposed to use them anyway. The shouting however got even worse: "That is not compatible! We need full backward compatibility! Keep it!"
Up until that moment we treated BackwardCompatibility from a practical point of view. We were ready to sacrifice it when we had a vague feeling it does not matter to keep it. However that one moment changed everything.
Since then I decided to treat compatibility seriously and keep 100% BackwardCompatibility. As I studied computer science at mathematics and physics faculty, I decided to apply as mathematical approach as I was able to find ways to really keep absolute compatibility. No excuses, no cheating, just 100% BackwardCompatibility. I guess NetBeans platform API compatibility history is a good proof showing we gained some knowledge in this respect.
To transfer that knowledge to my colleagues I invented an APIFest game (described in Chapter 17 of TheAPIBook). Playing such game really seems to improve the 100% backward compatibility skills. It comes with a bit academic approach, in real world one is usually OK with "99%" compatibility, but by taking things to extreme, the APIFest nicely shows the point.
Don't be afraid to ask us to prepare an APIFest game for you! Find out why BackwardCompatibility matters!
User comment by Daniel Latrémolière: Compatibility is highly important, but not broking compatibility sometimes can be complex (code difficult to read or problem for finding an asked method; by example). When an API need to be broken, then a good solution is broking API while insuring good binary compatibility by using a small compatibility layer for implementing old API on new API(s).
If the compatibility layer (no big idea in its code then no need of copyright) is released under an AS IS licence like BSD, the API user can use its code for refactoring easier its own code from old API to new API (with help of IDE). By example a non-modular API can be refactored in a non-modularized compatibility layer (for old users) calling two modularity-aware API (for new/updated users).
My reply: Thanks for leaving your comment. Yes, keeping the old APIs around may complicate time to market as newcomers may have hard time to find the way to do things right. Sometimes one wants to send old API to a blackhole - actually the Chapter 19, End Of Life Procedures of TheAPIBook contains description how one can keep BackwardCompatibility and still get rid of the old, deprectated APIs.
--JaroslavTulach 08:17, 30 August 2012 (UTC)
Is Invisible Method Signature Part of API?
Having a package private invisible abstract method in an abstract class effectively prevents anyone using such API to subclass it. This can be considered as good API design pattern, especially if such pattern is used since initial version of the API.
However it can also turn into a huge anti-pattern. Adding first package private abstract method into an abstract class is in fact an incompatible change. If the class used to be subclassable before, this prevents the subclassing and as such classes that used to compile may compile no more.
If the original version of a class contains one abstract method:
package api; /** version 1.0 */ public abstract class AbstractClass { public abstract void subclassMeAndImplementMe(); }
and later somebody adds a new implementation detail:
package api; /** version 2.0 */ public abstract class AbstractClass { public abstract void subclassMeAndImplementMe(); // hidden, not public new method abstract void youWillNeverImplementMe(); }
then we are facing an incompatible change. Inspite of not changing the visible methods of the class at all!
The hidden catch is that tools like Sigtest are unlikely to catch this situation, as they don't care about package private methods! Sigtest only emits a warning:
Warning: public class api.AbstractClass cannot be extended because contains the following member: method abstract void api.AbstractClass.youWillNeverImplementMe()
However warning is not enough, this is an incompatible change and it should be reported as such. The error should be same as in case somebody makes the youWillNeverImplementMe method public abstract. In such situation sigtest properly reports error:
Class api.AbstractClass: "E5.2 - Adding abstract methods" : method public abstract void api.AbstractClass.youWillNeverImplementMe()
Some people complained about unnecessary complexity of various OOP access modifiers - and they were likely right, but this case is worse (from the point of an API designer). So far API authors needed to care only about public and protected elements (as described for example in ClarityOfAccessModifiers), but it seems that we need to paly attention also to non-visible ones - a change to an implementation detail may change the published APIs!
--Apidesign 12:13, 20 March 2012 (UTC)
API Design is JavaOne Rock Star
My presentation about API Design Paradoxes has been rewarded as one of the more interesting ones during JavaOne2011. There is no video at the JavaOne rock star page, but as I keep repeating the presentation again and again with almost the same content, you can view the Linz 2009 version or Ostrava's 2011 translation to Czech.
It was fun to talk about Paradoxes, but I guess it is time to come up with something new. I'll try to resubmit my talk about AnnotationProcessors next year. Hopefully the just gained Rock Star status will give that talk few plus points and raise its chances to be accepted.
--JaroslavTulach 08:58, 20 January 2012 (UTC)
Beware of Friends! They'll Change You!
In case you are doing something for friends only (as many of facebookers do), you are in a great danger. Blindly increasing list of your friends is not for free. Because (as soon as you change list of your friends) you change yourself, you will immediatelly become different from outside.
This, in an API terminology means, you need to produce new version of yourself. Thus, when you publicaly state you have a new friends, version yourself! Read about FriendDependencies to understand why!
--JaroslavTulach 15:20, 19 September 2011 (UTC)
JDK7 Breaks JUnit Tests
Without the intent to blame JDK7 for being finally available, I have a concern to share. After switching the NetBeans test runs to use JDK7, most of the test suites started to fail randomly!
In case you are considering to switch to JDK7 and you have existing JUnit tests, consider including the time for stabilization of the tests into your migration plan.
--JaroslavTulach 12:33, 22 August 2011 (UTC)
API Designers: Are You Planting Forests or Gardens?
Today I have an unusual chance to talk about gardening (or planting forests) when designing APIs. The key concept to grasp is the ability to mount various types of APIs together. Btw. do you know that there are more types of APIs, right? Learning how to mount them together is an important knowledge that will determine whether your API or SPI will turn into a beautiful garden or fall into disorder of unmaintained, dark forest. Visit today's essay to learn how to properly mount client APIs and provider APIs so they can strengthen each other.
--JaroslavTulach 13:03, 21 March 2011 (UTC)
Using Netbinox hooks
Do you want to use extension hooks to extend behavior of Netbinox the same way you used to extend Equinox? Before version 1.16.7 this used to be complicated, but as this little tutorial shows, now hooks can be registered easier than ever.
--JaroslavTulach 15:49, 29 January 2011 (UTC)
Beware of Using Enums
Have you ever thought that enum in JDK5 is good idea? Then welcome to the club. I used to think that as well. But it is not, when it comes to API design. Read why to understand its gotchas.
--JaroslavTulach 22:04, 12 January 2011 (UTC)
Visualize Lookup
There is a very nice visualization of Lookup and its family on the ImageJ web site. It is created by MindMap and I find it quite explanatory. In case you ever wanted to sort your thoughts about Lookup, this mind map] is definitelly going to help.
--JaroslavTulach 16:24, 10 January 2011 (UTC)
Access Facebook from a Desktop Application
Having trouble to access Facebook from your desktop application? I know how to help you out of your missery. Read the story and source code for my Feedbook desktop application - application that I use to re-publish my blogs from this site to my Facebook account.
--JaroslavTulach 19:46, 16 November 2010 (UTC)
One ClassLoader to Know Them All!
Modularizing monolithic application into individual pieces has various benefits. For example classes will be well isolated from each other. However there can also be pitfalls. For example classes can be too much isolated from each other and Class.forName can yield bunch of ClassNotFoundExceptions. What you need in such situation is a classloader that knows everything. Here is a little essay about problems you can face when building it.
--JaroslavTulach 10:35, 9 November 2010 (UTC)
Removing protected abstract Methods is no Longer Source Compatible
Rijk van Haaften noticed today that removing protected abstract methods (which used to be source compatible) is no longer compatible at all. I am adding his comment to errata for chapter 6. Please find Rijk's observation there.
--JaroslavTulach 07:44, 8 October 2010 (UTC)
JDK6 API for SQL Syntax Completion
Do you know that there is a standard Java API for extending any IDE with code completion? That you can easily, without writing any IDE plugin show list of SQL tables inside strings? Learn more, try out whether your favorite Java IDE comes with real support for Annotation Processors. If not, make a switch to the best IDE that does that!
--JaroslavTulach 18:56, 29 August 2010 (UTC)
LiveDB: Make Your Database Schema Part of Your Sources
I really hate when something is defined at two places. Things like that may easily get out of sync and where is the truth then? I am glad that my little LiveDB experiment shows one more field in Java where such duplication may no longer be necessary: with LiveDB you can access schema of your database live. Live not only during compilation, but also during developement from inside of any good IDE.
Get the LiveDB sources to learn more. Watch our LiveDB screen cast. Share your thoughts!
--JaroslavTulach 17:17, 30 July 2010 (UTC)
Equinox Compatibility Shaking
While trying to upgrade from version 3.5 to 3.5.2 I noticed some EquinoxCompatibility problems. Why can't an upgrade of a minor version of some library be just a plain drop in replacement? How can someone rely on a library which shakes its behavior like an amoeba?
--JaroslavTulach 09:34, 13 July 2010 (UTC)
Equinox is not Ready for Modular Environment!
Today I noticed one bootstrapping problem with Equinox which makes it completely unusable for execution in modular systems. Rather than fixing it I decided to write (thought) provoking blog about problems BootstrappingEquinox. I hope it will help everyone understand how bad the situation is and encourage creation of proper fix.
--JaroslavTulach 08:20, 7 May 2010 (UTC)
Unbearable Painfulness of Being Stateful
Do you know the feeling like this? Something leaves strong impression inside you. So strong that you want to speak up. Later you calm down. Then you get into similar situation again. This time you want to scream. Then you forget. At least you try. But the nightmare comes back again, and now you can't remain silent.
This happens to me particularly when using one specific NetBeans API. For a while I was just complaining to myself, but then I realized the cause of the problem. The API was properly reviewed (even by me) and looked OK, but as time shows, there is a hidden catch: It is too stateful! It is easy to write program that compiles against that API. It is much more harder to create a program that also executes without throwing runtime exceptions.
Have you ever had similar experience? Has it been also because of the API being too stateful? Compare your experience with mine.
--JaroslavTulach 14:29, 2 May 2010 (UTC)
The Fastest OSGi Container
Are you seeking for the world's fastest OSGi container? Then you are on the right blog - since yesterday the OSGi container with fastest start is provided by NetBeans!
--JaroslavTulach 12:15, 2 April 2010 (UTC)
Introduce Yourself to Your Mirror!
Are you talking to yourself when standing in front of a mirror? Are you properly introducing yourself to your mirror picture? No!? Well, you should be. Good communication protocols require people to introduce before the real chat starts.
To improve your design skills, I suggest you to do it even dealing with a man in the mirror!
--JaroslavTulach 03:38, 25 March 2010 (UTC)
Reach harmony. Play Single-tone!
A step by step cook book for properly using Injectable Singletons is now available. In case you ever wanted to expose your application state, the Injectable Singletons approach gives you sound, simple, testable and extensible way to do it. I don't expect a massive migration from DI to Injectable Singletons, but in some situations this pattern may be handy. If you find Injectable Singletons useful, share your experience with others.
--JaroslavTulach 20:12, 9 February 2010 (UTC)
Overcome Your Fear of Being Single(ton)!
Have you ever felt lonely like a singleton? I do from time to time. Especially when I get a feeling that I cannot break through and outreach people who I'd like to talk to.
Surprisingly this often happens when trying to talk to DI community. I cannot enumerate how many times I heard: "This is not DI!" "Singletons are wrong!" "Learn to use Spring and then come back!" Looks like I have a problem with DI guys. But that is not true, I like DI, I've (already) learned a lot about it! It is more that some DI proponents seem to have problem with us. It usually go like this: A Joe Developer after being hurt few times by coding without DI, learns about DI, finds it amusing, uses it successfully, things start to make sense. Then, rather then being happy that Joe's own projects are fine, Joe starts to evangelize the right way to code. What is not DI is wrong or at least old fashioned, and deserves a rewrite. It actually does not matter what it is, but if it is not using DI, it has to be bad.
The problem is that Joe never investigates what the other technology is, never tries to understand whether it is wrong or not. Joe has pre-made answers for everything. Joe's opinion is straighten inside of own community. The fact that the community is rapidly growing ensures Joe that this is the only way to deal with programming. Everyone else needs to convert, or be crucified. The faster, the better. Don't waste time trying to understand the others!
As a result not many DI fans outreach and give us a chance to speak up. Thus I am very glad that Witold Szczerba did it, and asked very interesting question with a lot of good reference material. As a result I could sort out my own thoughts and create a defense of singletons.
Don't be afraid of singletons! They are quite friendly if you know how to use them!
--JaroslavTulach 08:26, 25 January 2010 (UTC)
Tim Boudreau on Lookup
In response to a mailing list question Tim decided to explain everything you ever wanted to know about Lookup but were afraid to ask.
--JaroslavTulach 08:59, 20 January 2010 (UTC)
Video: Paradoxes of API Design
Do you want to learn something about API design while watching TV? Then you need to get my show from Blip TV!
--JaroslavTulach 11:28, 12 January 2010 (UTC)
The Little Manual of API Design
When googling around for new references to my book I found out a year old PDF from Trolltech. Nice condensed introduction to API design for C++ was written down by Qt developers: troll.no. There is not much new topics covered, compared to TheAPIBook, but some observations are ammusing. I especially like the little differences and strange similarity of the C and Java worlds.
The pdf may be nice example that when the time comes, the same things start to independently happen in different places at the same time. TheAPIBook went to publishing May 4, 2008. The little manual is dated Jun 19, 2008..
--JaroslavTulach 13:50, 28 November 2009 (UTC)
Avoid Visitors. Unless you really know them.
Visitor pattern is one of the well known OOP patterns. However using it in an API is dangerous. At least unless you have read chapter 18 of TheAPIBook or studied my sample code.
--JaroslavTulach 08:59, 24 November 2009 (UTC)
Podcast: AOP is not dead. If you know how to use it!
Recently I saw the future of AOP. I thought one should say goodbye to AspectJ and its clones and get ready for ease of use that makes AOP wide spread! After few comments I know that it is enough to learn more advanced capabilities of AspectJ. But don't forget to do so, such flavor of AOP is much better than plain writing of aspects.
--JaroslavTulach 12:56, 21 November 2009 (UTC)
Screencast: Module System for Java
Module system is single, most important missing feature of Java. It is essential for the vitality of the Java system to define and agree on shared standard. On shared common ground. Recently me and Geertjan created a recording where we discuss why it is important to have it. We also demonstrate on the NetBeans and Mylyn synergy how such system would simplify our lives. If you have half an hour, listen to our screencast and join us with comments.
--JaroslavTulach 09:07, 27 October 2009 (UTC)
The End of MVC as We Know it
Geertjan literally forced me to record a screencast about DCI with him today. We did rehearsal over lunch and beer (quite lively and interactive). Then he drag me into the recording room and we did it (less interactive, but more serious and important).
Join us to learn why MVC days are over and you should switch to a new paradigm ready for the 21st century!
--JaroslavTulach 20:52, 22 September 2009 (UTC)
@Synchronized
Synchronization is getting more and more important in applications and libraries written these days. However synchronization is hard. The primitives available in Java (or other languages), are ... well, are primitive. Higher level abstractions are available, but still they don't guarantee completely deadlock prone system. This has all been discussed in Chapter 11, Runtime Aspects of APIs.
Java Monitors just aren't what they supposed to be (read why). Thus I am glad to see that the project Lombok's @Synchronized seems to successfully replace the synchronized keyword with annotation (vivat annotations!).
In the name of cluelessness of your Java API users, don't forget to prefer private locks to synchronized methods. Or switch to the beautiful @Synchronized annotation.
--JaroslavTulach 08:51, 7 September 2009 (UTC)
XML, Schema, SAX. @Annotations!
Some say that code completion with annotations is not big improvement. XML can have code completion too if we give XML Schema with it. I disagree! Anyone to comment on that?
--JaroslavTulach 10:35, 31 August 2009 (UTC)
Extend Inextensible!
Interfaces are not extensible. Learn how to extend them!
--JaroslavTulach 11:31, 19 August 2009 (UTC)
Try to Steal my Object!
Recently my cousin was teasing my mind with a question whether there is a way to make anything private in Javascript. I may be wrong, but I think there is: Is there anyone who can steal and modify my internal impl object?
--JaroslavTulach 04:35, 5 August 2009 (UTC)
Plug into Your Compiler! Optimize Your Framework by Generating Compile Time Caches.
Learn how to generate CompileTimeCaches with a little help of source-only annotations and their AnnotationProcessors.
--JaroslavTulach 14:08, 25 July 2009 (UTC)
Victims of Conceptual Surface
Do you know how to eliminate classes with too many dependencies like java.beans.Beans? You need to Sneak in Simplicity!
--JaroslavTulach 16:32, 22 June 2009 (UTC)
Splitting applet and beans via CodeInjection
I have a basic infrastructure to split the JDK which could be useful in your project as well. Also I managed to successfully split java.beans and java.applet packages.
--JaroslavTulach 12:39, 17 June 2009 (UTC)
Help me modularize JDK
Creating modular JDK while keeping compatibility with the existing monolithic one may be tricky. Will you help me find right way to do it?
--JaroslavTulach 20:14, 14 June 2009 (UTC)
Everyone is equal. Except Power Users.
Learn to design Privileged API suitable for power users of your library. Don't forget to listen to podcast #3.
--JaroslavTulach 17:01, 25 May 2009 (UTC)
Double Injection. Loosely Coupled SpringFramework.
I have just finished the bridge between Spring and Lookup (originally written by AndreiBadea) and prepared a demo application to demonstrate what it can be useful for.
--JaroslavTulach 04:43, 28 April 2009 (UTC)
Clear Definition of Version
Interfaces are absolutely perfect tool to achieve ClearDefinitionOfVersion. A curious reader question made me write the ClearDefinitionOfVersion page - many thanks for your talkback.
--JaroslavTulach 19:55, 24 April 2009 (UTC)
Lookup is Free!
Time to pickup cherries! Nobody can know what happens to NetBeans after the Sun/Oracle acquisition. Better to be ready for everything and save the NetBeans API pieces that make sense outside of the project boundaries. One of them is Lookup. I am proud to announce that Lookup has new home now: lookup.apidesign.org. Welcome the refugee and let me know if there is a way I could improve the library.
--JaroslavTulach 05:54, 21 April 2009 (UTC)
D2D: Factory instances are more flexible than factory classes
As part of Designers To Designers section on this website I seem to have a unique chance to introduce Factory instances are more flexible than factory classes article by (yet) unknown designer. Enjoy, talk back.
--JaroslavTulach 08:40, 18 April 2009 (UTC)
Can there Be Implement Only Interface?
Here is my answer to question that I got by parren.
--JaroslavTulach 18:20, 12 April 2009 (UTC)
Application Context in Ruby
Recently I've noticed a lot of activity in the apidesign.org wiki. Perfect. Inspite it is more posts than I can handle.
However I am thankful for all your comments and I hope this wiki can become a place for exchange of ideas between people interested in API design. For example, Steve Shapero added a note about his will to seek for Application Context implementation in Ruby. I personally cannot be really useful, as my knowledge of the Ruby language is quite basic, but maybe some of you will join Steve's effort.
PS: Let us know how it went. You know, I feel that Ruby's duck-typing and API contracts may not be mutually strengthening...
--JaroslavTulach 19:30, 11 April 2009 (UTC)
Get Rid of Multi-Meaning Classes
In the latest example related to modifiers, I'll explain how to achieve even more clarity than advocated by EliminateFuzzyModifiers essay. Today we are going to eliminate multi-meaning classes!
--JaroslavTulach 16:42, 1 April 2009 (UTC)
Eliminate Fuzzy Modifiers!
Time for new post about modifiers. My recent take on access modifiers generated quite a bit of interest. I've received a bunch of comments and I am thankful for all of them! I've learned about approaches taken by different languages, I've started to think about my future, but more importantly Arno Nyhm asked me to:
- please show not only a bad example for the Factorial
- but also a good solution for this implementation.
At your wish Arno! Enjoy (almost) real world example how to EliminateFuzzyModifiers! And let me know what you think.
--JaroslavTulach 20:50, 27 March 2009 (UTC)
Time to Fix Java Access Modifiers!
I have an open letter to designers of Java language for JDK7: Can you please make Java modifiers API-friendly?
--JaroslavTulach 22:14, 25 March 2009 (UTC)
Co-exist in Peace! Accept Alter Ego.
APIs age and from time to time they get into so bad state that they need an alternative reimplementation. At that time one has to face a dilemma: Keep BackwardCompatibility or break it and improve the API? As AlternativeBehaviour page explains there is no contradiction between these two. One can deliver improvements while retaining BackwardCompatibility. All that is needed to teach the API to accept its Alter Ego.
--JaroslavTulach 16:56, 16 February 2009 (UTC)
Beware Exposing Yourself to Public!
Erwin Vervaet asked me to provide an explanatory example:
- I have a question regarding chapter 11, section "Pitfalls of Java Monitors".
- Could you please provide an example illustrating the problem, where
- subclasses interfere with the parent class's monitors?
It took me a while to expose that example, but here finally is my newest page talking about Pitfalls of Java Monitors.
--JaroslavTulach 10:15, 12 February 2009 (UTC)
Try, catch, and don't give up!
When your call to a method generates an exception, what can you do? Print warning and give up? Yes, often. Unless the TryCatchRedo pattern is in use!
--JaroslavTulach 15:29, 2 February 2009 (UTC)
Accept Unacceptable!
When you maintain some code and you get a patch that you do not like, what can you do? Is the only option to refuse the change, or is there a better way? Of course, as this was just a rhetorical question, there is better solution: Just create a code slot!
--JaroslavTulach 21:31, 10 January 2009 (UTC)
Singletonize your own Factories!
I am reading my own book and I've just got to page that talks about a pattern called among the NetBeans team Singletonizer. TheAPIBook describes it with a small note, but as I think it is very useful, I've just created a dedicated page describing it in more detail, giving it more, well deserved, publicity.
--JaroslavTulach 16:29, 25 December 2008 (UTC)
Wizard is the best API
There is a nice discussion provoked by description of my manifest advantures. It reminds me once again how important tools are. As I wrote somewhere in TheAPIBook, I guess it is in Chapter 9, one of the best APIs is wizard. Good wizard can turn any API, regardless how bad, into perfectly shining, beautiful star. Good tools make everything easier.
--JaroslavTulach 13:49, 19 December 2008 (UTC)
Builder vs. Cumulative Factory
Is Builder better pattern than CumulativeFactory? As Radim and Paulo pointed out, it might be. However from my point of view, it is an extension to the previous one! Read more and help us decide...
--JaroslavTulach 13:02, 15 November 2008 (UTC)
Cumulative Factory API Design Pattern
Dear API writers, let me introduce you to cumulative factory API Design Pattern. Read more...
--JaroslavTulach 15:38, 9 November 2008 (UTC)
How Many People Have to Die leakages
Recently I've been warned that my sidebar in Chapter 4, Ever Changing Targets talks about events that are completely ununderstandable for international readers. That made me write a short essay about leakages of cultural contexts and the similarities with the API Design.
--JaroslavTulach 05:01, 21 October 2008 (UTC)
Exceptions in API
Casper Bang asked following question about exceptions in API after reading the TheAPIBook:
I was curious as to know how come, in a book strictly about API design in Java, you do not mention exceptions (particular checked exceptions) and the role they play in documenting assertions vs. hampering versionability. Did you simply think this to be too controversial an issue I wonder?
Good question! Inspiring. Here are my current answers: exceptions in API.
--JaroslavTulach 21:37, 14 September 2008 (UTC)
Have You Ever Wondered?
Many people want to know, before they start to read a book, whether it can help them solve some problems they have faced. That is very likely reason why many books start with have you ever wondered sections. The Practical API Design book does not contain such section itself, however that in no way means that there it is not helping to solve problems! You can bet that there is a lot of useful advices! The book is a lab journal describing adventures of NetBeans project and as such, it is almost completely stuffed with problem solutions. Here is short online version of Have You Ever Wondered to demonstrate that. Visit the page and check yourself what problems can TheAPIBook solve for you!
--JaroslavTulach 20:42, 17 August 2008 (UTC)
Request/Response Pattern Revisited
Here is few additional thoughts about Request/Response which did not make it into TheAPIBook's explanation of Request/Response pattern.
--JaroslavTulach 21:02, 25 June 2008 (UTC)
Follow
