Java 1.5, but still support Java 1.4 using Retrotranslator, Retroweaver, or using -target jsr14:
Thomas Mueller
So far the H2 source code is compatible to Java 1.4. I like to use
generics, extended for loops, and so on. Java 5.0 concurrency
utilities are not required and I don't plan to use them in the near
future.
Java 1.4 could still be supported using Retrotranslator, Retroweaver,
or using -target jsr14:
http://www.ibm.com/developerworks/java/library/j-jtp02277.html
http://retrotranslator.sourceforge.net
http://retroweaver.sourceforge.net
Would this be a problem for anybody? Does anybody have experience
using any of the above technologies?
Regards,
Thomas
P.S. I didn't know about -target jsr14. Here is an example:
public class TestJSR14 {
public static void main(String[] args) {
for(String a : args) {
System.out.println(a);
}
}
}
javac -source 1.5 -target jsr14 TestJSR14.java
Thomas Kellerer
has been de-supported by Sun?
Even 1.5 will be de-supported by Sun end of this year (October).
Just my .02€
Thomas
On 16 Mai, 12:20, Thomas Mueller <thomas.tom.muel...@gmail.com> wrote:
> Hi,
>
> So far the H2 source code is compatible to Java 1.4. I like to use
> generics, extended for loops, and so on. Java 5.0 concurrency
> utilities are not required and I don't plan to use them in the near
> future.
>
> Java 1.4 could still be supported using Retrotranslator, Retroweaver,
> or using -target jsr14:
>
Jan Kotek
I was using retrotranslator before, it works very nice. It does not
just 'strip away' everything, but have it's own implementation of
enums and other things. It also handles some 1.5 specific classes (for
example StringBuilder is replaced by StringBuffer).
I would recommend providing two distribution jars (one native 1.5
bytecode, one backport to 1.3). Native 1.5 bytecode can run little bit
faster.
Regards,
Jan
Thomas Kellerer
supported Java version?
On 17 Mai, 14:02, Jan Kotek <openco...@gmail.com> wrote:
> Hi Thomas,
> I was using retrotranslator before, it works very nice. It does not
> just 'strip away' everything, but have it's own implementation of
> enums and other things. It also handles some 1.5 specific classes (for
> example StringBuilder is replaced by StringBuffer).
>
> I would recommend providing two distribution jars (one native 1.5
> bytecode, one backport to 1.3). Native 1.5 bytecode can run little bit
> faster.
>
> Regards,
> Jan
>
> On Sat, May 16, 2009 at 6:44 PM, Thomas Kellerer
>
>
> > I don't think support for 1.4 is important. How long is it that this
> > has been de-supported by Sun?
>
> > Even 1.5 will be de-supported by Sun end of this year (October).
>
> > Just my .02€
>
> > Thomas
>
> > On 16 Mai, 12:20, Thomas Mueller <thomas.tom.muel...@gmail.com> wrote:
> >> Hi,
>
> >> So far the H2 source code is compatible to Java 1.4. I like to use
> >> generics, extended for loops, and so on. Java 5.0 concurrency
> >> utilities are not required and I don't plan to use them in the near
> >> future.
>
> >> Java 1.4 could still be supported using Retrotranslator, Retroweaver,
> >> or using -target jsr14:
>
Alex
It's not important to compile using 1.4, but it is important to
support it at run time.
We are using H2 on a couple of embedded devices using Java 1.4
(unfortunately with mixed results because of the various H2 bugs).
On May 17, 1:05 pm, Thomas Kellerer <google-gro...@sql-workbench.net>
wrote:
Thomas Mueller
> I would recommend providing two distribution jars (one native 1.5
> bytecode, one backport to 1.3). Native 1.5 bytecode can run little bit
> faster.
So far the jar file included in H2 is at level 1.4, and I don't plan
to include a jar file for 1.3. But maybe I will automate how to create
a 1.3 or 1.4 version. Or document, but if retrotranslator is as good
as I read then it would be just "use retrotranslator".
> The question is: why would any serious project still use an de-supported Java version?
There are two reasons: first, some companies still use Java 1.4 even
if it is not supported any longer. Second, small devices. However even
Android supports Java 1.5 source code, so that shouldn't be a problem.
I don't plan to support every (old) platform, because that would take
too much time and would slow down development.
> We are using H2 on a couple of embedded devices using Java 1.4
What platforms are those?
> unfortunately with mixed results because of the various H2 bugs
What kind of bugs are those?
Regards,
Thomas
Alex
> What platforms are those?
>
One of the platforms is CEEJ - http://www.skelmir.com/products/ceej.html
This is an independently implemented JVM which is somewhere at 1.4.2+
level (i.e. some Java5 features are supported, but far from all of
it).
> > unfortunately with mixed results because of the various H2 bugs
> What kind of bugs are those?
past..., database corruption, etc.
The last big one for us was the problem with "select * from table
order by column" returning zero results for a non empty table because
of some kind of index problem that was recently fixed.
The performance on Flash (NAND) file systems is also fairly poor
mostly because of the large number of small write operations executed
by H2.
Thomas Mueller
>> What platforms are those?
> One of the platforms is CEEJ - http://www.skelmir.com/products/ceej.html
> This is an independently implemented JVM which is somewhere at 1.4.2+
> level (i.e. some Java5 features are supported, but far from all of
> it).
That means, you probably don't even need Retrotranslator. I don't plan
to use any special features of JDK 1.5. Just generics, StringBuilder,
extended for loops, autoboxing, Integer.valueOf(..) and so on, and
maybe varargs.
> The performance on Flash (NAND) file systems is also fairly poor
> mostly because of the large number of small write operations executed
> by H2.
This should be solved in the new storage mechanism ('page store'). It
is still experimental, and many test cases still fail (you can also
get a corrupted database very easily when using it). If you want, you
could try. You would need to download the trunk and build it yourself.
To enable it, set the system property h2.pageStore to true.
Regards,
Thomas