JVx with Java6
JVx was based on Java5 and all releases, including 2.1, were built with JDK 1.5. We thought it could be the time for a change and Java5 is not popular nowadays. With JVx 2.2 we'll switch to Java6. It wasn't important for us because JVx has no specifics that need Java6, but some 3rd party libs like RESTlet need Java6. The client-side code of JVx will probably work with Java5 but we'll build our releases with target 1.6.
We made an update to RESTlet 2.2.3 because of some useful changes and also for the side-project JVx.mobile. So we had to switch to Java6 as well. Our repository is already based on Java6 and we started migration of dependent projects and build tasks.
Because of some changes in DBAccess regarding DataSource support, it was also a good idea to use new JDBC drivers and most new drivers are not available for Java5. So we hope you understand why Java6 was a good idea.
The current nightly build was created with Java6. Give it a try.
Development | rjahn | 17/12/2014
RSS-Feed
Wouldn't it save some time in the future if you switch to java 8 now instead of switching from a really old java version (1.5) to an old one (1.6)
Would be easier but you can't do that as framework developer.
We need maximum compatibility and it would be best to be source compatible with 1.5 but 3rd party libs aren't, so we use 1.6.
1.8 would mean that all clients need 1.8. This is not possible for Oracle Forms customers and some application servers!
1.6 doesn't hurt. JVx will work with 1.8 too
Yes, it would save time in the future if we would directly jump from 1.5 to 1.8, and then directly to 1.9 and so on. But as rjahn pointed out, that is not a so good idea for various reasons.
Let me explain, in corporate and industrial environments, uptime and stability is all that matters. Updates (not to mention upgrades) have to be planned weeks in advance, tested and tested again to make sure that they do not produce any downtime or the least possible downtime. Upgrades, like swapping machines for new ones or changing to a completely new version of software, are planned months to a year in advance. And if it works, you better not touch it. You can't simply install the newest version of Java and hope that it doesn't have any bugs, it has to be tested first. For example, I know that the Linux kernel developers sometimes have a lag of two to three years between breaking something and somebody finding out, that's not because nobody does use it, but because the industry is two to three years behind the current version. So if somebody breaks something in the new 3.18 release of the Linux kernel (which is a few weeks old), the industry will start evaluating and testing that version and will find the bug in 2017.
Pumping the minimum Java version of JVx to 1.8 would leave a lot of our users, clients and customers between a rock and a hard place, as there's a good chance that their environment will be upgraded to 1.8 by, if they are lucky and we take a very optimistic guess, 2017. That's over two years that they can't use any updates from JVx except if they'd backport them, which can be a very tedious work (and if we'd use 1.8-only features it would result in a plain rewrite of said code).
Of course there's also a egoistic component in this, as we sell software we can't simply be incompatible with many environments. Nobody will buy our software if it's incompatible with whatever they have.
And last but not least, there have been substantial changes between 1.5 and 1.8. It's not a must, but it would be nice if we would take advantage of these changes. If we'd jump from 1.5 to 1.8 it would require as to touch and rewrite a lot of code, too much in my opinion for one release. As much as the developer in my cries to get the newest and shiniest toys, we need to make small steps towards them. It's good pace for everyone, it's a good pace for us.