<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: JVx with Java6</title>
	<atom:link href="http://blog.sibvisions.com/2014/12/17/jvx-with-java6/feed/" rel="self" type="application/rss+xml" />
	<link>https://blog.sibvisions.com/2014/12/17/jvx-with-java6/</link>
	<description>Blog @ SIB Visions</description>
	<lastBuildDate>Wed, 05 Mar 2025 13:10:49 +0100</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: rzenz</title>
		<link>https://blog.sibvisions.com/2014/12/17/jvx-with-java6/comment-page-1/#comment-461</link>
		<dc:creator>rzenz</dc:creator>
		<pubDate>Tue, 23 Dec 2014 09:09:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sibvisions.com/?p=3452#comment-461</guid>
		<description>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&#039;t simply install the newest version of Java and hope that it doesn&#039;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&#039;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&#039;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&#039;s over two years that they can&#039;t use any updates from JVx except if they&#039;d backport them, which can be a very tedious work (and if we&#039;d use 1.8-only features it would result in a plain rewrite of said code).

Of course there&#039;s also a egoistic component in this, as we sell software we can&#039;t simply be incompatible with many environments. Nobody will buy our software if it&#039;s incompatible with whatever they have.

And last but not least, there have been substantial changes between 1.5 and 1.8. It&#039;s not a must, but it would be nice if we would take advantage of these changes. If we&#039;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&#039;s good pace for everyone, it&#039;s a good pace for us.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rjahn</title>
		<link>https://blog.sibvisions.com/2014/12/17/jvx-with-java6/comment-page-1/#comment-460</link>
		<dc:creator>rjahn</dc:creator>
		<pubDate>Wed, 17 Dec 2014 13:34:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sibvisions.com/?p=3452#comment-460</guid>
		<description>Would be easier but you can&#039;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&#039;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&#039;t hurt. JVx will work with 1.8 too ;-)</description>
		<content:encoded><![CDATA[<p>Would be easier but you can't do that as framework developer.</p>
<p>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.</p>
<p>1.8 would mean that all clients need 1.8. This is not possible for Oracle Forms customers and some application servers!</p>
<p>1.6 doesn't hurt. JVx will work with 1.8 too <img src='https://blog.sibvisions.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: melen</title>
		<link>https://blog.sibvisions.com/2014/12/17/jvx-with-java6/comment-page-1/#comment-459</link>
		<dc:creator>melen</dc:creator>
		<pubDate>Wed, 17 Dec 2014 13:13:36 +0000</pubDate>
		<guid isPermaLink="false">http://blog.sibvisions.com/?p=3452#comment-459</guid>
		<description>Wouldn&#039;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)</description>
		<content:encoded><![CDATA[<p>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)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
