The future of software development according to Seppia

a.k.a. (the beginning of) Our manifesto.

• Don't write your application. Assemble it 
  
  Let's face it: whatever application you have in mind you are going to need some third party software.The more sophisticated your application, the more third party software.
  
  If you don't agree and you think you can write a new application all on your own (or with your team of faithful followers) we probably should be more clear about what we intend by "application". Here we are talking about a piece of software that does its job: one that is used by people who find it useful, reliable and functional. We are talking about building quality software delivered in time. We are talking about flexible software that is easy to maintain.Yes, because when successful software is delivered , it's not "thank you very much and good night" but it demands to grow and it does grow...
  
  Now unless you were on the moon in the last few years you must have noticed that there has been a proliferation of many jars, APIs, open source projects, freebies,...  all of them few clicks away from you. 
  Now some are good and some are very bad.
  You want to write an application, you need to learn to choose the good ones from the bad ones.
  Familiarize with them, study them, make them  interact with each other and write the least amount of code. Yes, because that is the only code you might want to debug.
  
  
  
• Make your application classpath-less 
  
  I know you learnt java and you know how to set up your classpath. I know you have probably answered the questions of some of your colleagues asking why they were getting a java.lang.ClassNoDefFoundError you are missing such and such jar - was your answer.
  Sometimes was even more tricky:  you are use using an old jar... you need to use version such and such.
  
  Too sad. That's not the way forward. Those embarassingly long classpaths that you need to manually change on every installation because your client is using a different jms, jdbc, or whatever else...
  
  Did you know that you could write a tiny program that containing only imports from the core J2SE APIs. and using a URLClassLoader can load all of its Java resources (jars included) from subfolders. That bootstrap program can then launch any application.
  
  Incidentally this is how both Seppia and the Eclipse Plugin Architecture work.
  
  
  
• Glue your component-based-software together with Javascript 
  
  How many times have you heard of component based software ? Plugin architectures ? Modularity ? 
  Loads. 
  So what's the problem with them ? None. 
  So why should your application be different ? It should not. End of the story !  
  I know ... I know you have been too busy building your application that you forgot to think of its foundation.
  
  So what exactly is a module in seppia ? 
  A module is that "piece" in your software that provides certain functionalities via some javascripts. The javascript code can access the classes of the jars associated with the module and easily perform its task. It can also delegate some of its work to other javascripts or other modules (more precicely other javascripts in other modules).
  Did you get it ? Probably not... don't fool yourself. Read it again: 
  A module is that "piece" in your software that provides certain functionalities via some javascripts. The javascript code can access the classes of the jars associated with the module and easily perform its task. It can also delegate some of its work to other javascripts or other modules (more precicely other javascripts in other modules).
  
  Now at this point there is the most frequenly askes question: Why javascript to define the functionality of a module why not to use XML ? 
  We like XML but we are not XML addicted. We like using XML when we need to use it but not when it's not its natural place*. 
  
  If you want to glue a few jars together and provide a new service we want to achieve this by 
  1) placing the jars in one folder
  2) write one or few javascripts that create java objects, interrogate them and handle naturally any conditional step.
  
  Too often people are over-eager to use XML configuration files, while a scripting language makes a straightforward and powerful configuration mechanism.
  
  Have you read this far ?  Thank you very much dear reader. We hope you will enjoy Seppia as much as we enjoy writing it (that means a lot). All The best.
  
  
  

  
  

  ---

  ^{* For example so many people are trying to write frameworks to configure swing application via xml files, good luck to them but they are doomed to fail. XML can be great to describe some data but it does not work well where a scripting language is more suitable.}