Moving to JPedal release 8

A little bit of history

JPedal 8JPedal and IDRsolutions have been around for a few years now. I setup IDRsolutions  in 1999. I am now the only one of the original team left. Phil has retired and Brendan fulfilled his lifetime ambition to go back into Academia. Not sure if I should regard my still being here as a good or a bad thing….

Our first product was a tool called Storypad which News Corp used to help publish The Times, and The Sun newspapers on the Internet. We built our second product, a more generic publishing solution called JPedal, from Storypad. I suspect there may still be a few lines of Storypad code in there….

Since we started JPedal, the product has developed considerably and the market (and indeed the world) has changed out of all recognition. Java has come full circle, starting out as embedded/server solution which spawned applets and clients and is now back on the server. Oracle has now changed the Java development model from once a decade or so to every six months. So it seems a very good time to take stock of our code base and have a big code review….

A big code review

We set ourselves several targets in our code tidy.

  1. Try not to break anything. No public APIs have changed.
  2. Remove code which no longer makes sense. We have code to handle Applets (now dead), we added some code to use IText before it became commercial/AGPL, we looked at using Rhino to support JavaScript but now have a much better solution with our BuildVu/FormVu products, etc.
  3. Remove dead code – we have been using a whole selection of tools to spot unused variables, methods and constructors which are not part of the public API and unused.
  4. Improve security. We can now encrypt any data we cache on the local drive and variables, classes, etc are now locked down as tightly as possible.
  5. Take advantage of Java8. We now have a code base level of Java8 and make extensive use of Lambda and other Java8 features.
  6. Tidy-up old methods and rewrite code to make it cleaner.
  7. Make it easier to adapt to future Java developments. We use Javafx for a coverflow mode. Javafx will disappear in future core Java versions so we have made the code more modular to cover this.

This represents a huge change to the code base so we have updated the release to version 8 to signal this.

The payoff

The benefits of this should be a leaner and cleaner code base which we can develop faster and better fits the needs of our customers over the next 20 years. I look forward to sharing with you 40 years of IDRsolutions then.

If you’re a first-time reader, or simply want to be notified when we post new articles and updates, you can keep up to date by social media (Twitter, Facebook and Google+) or the Blog RSS.

 

Related Posts:

The following two tabs change content below.

Mark Stephens

System Architect and Lead Developer at IDRSolutions
Mark Stephens has been working with Java and PDF since 1999 and has diversified into HTML5, SVG and JavaFX. He also enjoys speaking at conferences and has been a Speaker at user groups, Business of Software, Seybold and JavaOne conferences. He has a very dry sense of humor and an MA in Medieval History for which he has not yet found a practical use.
Markee174

About Mark Stephens

Mark Stephens has been working with Java and PDF since 1999 and has diversified into HTML5, SVG and JavaFX.

He also enjoys speaking at conferences and has been a Speaker at user groups, Business of Software, Seybold and JavaOne conferences. He has a very dry sense of humor and an MA in Medieval History for which he has not yet found a practical use.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>