Abstract: We will describe our journey into setting up minimalistic development environment at eBay. Developers tend to include many source projects in their workspaces because they may potentially need to view, debug or otherwise tinker with included source. While viewing and debugging are possible with precompiled project libraries (jars), they don’t allow one to make modifications.
We describe dynamic projects as a way to bridge this gap by allowing developers to include projects in their binary form with an option to convert them to source projects! Like PDE but with regular JDT projects. This can be taken a step further by including only the source files being modified while having the rest of them come from their binary form. This is done by manipulating classpath which can elegantly be handled using custom classpath container.
With the dynamic projects, as much of the code is brought as binary, we run the risk of not caching the compilation issues due to source changes that affect their dependent binaries. We describe technique used to detect such binary compatibility breakage that would have gotten caught if those elements where coming as source.
Developers tend to import or create all the source projects they need before hand and compile and build everything even if they don’t edit it. There is a reason why they do that. They want to see the source, put break points, run individually, basically they want to play around with it a little bit.. This is exactly what dynamic projects enable them with i.e. cater all the facilities of a source project without the overhead of compilation. As we all know nothing comes for free, we need to build the binary and source jars for these projects and keep them available for using it in the dynamic project. Once the developers decides to edit a file, that’s when we provision the source as real source and compile it.
Let us take it to the next level, Till now we treated the whole project or a jar as a single unit. Why even that? How about we convert only the single file you want to edit. Amazing huh??. That’s what really makes the dynamic projects big. Here we let the developer modify just the files he wants to edit, and the rest of the code comes as binary from the jar files. The whole classpath complexity associated with the above two use cases is being handled inside of a custom classpath container.
Let us try to make it a little more interesting by detecting binary compatibility in this scenario. One of the biggest problems with libraries especially utility libraries is that changes to the API might break the binary compatibility. Earlier, this type of errors were be detected by compiling the consumer source code and if the consumers are binaries. In the worst case if consumers are not recompiled against the changed API,, then these errors will be manifested as run time errors there by breaking the production. Here we are addressing this issue, by detecting the binary compatibility breakage inside of the jars on the fly. Basically as and when user edits it, we signal the user if he breaks an existing consumer with his change.