Well, because the chance of happening different behavior is random and very
small, it's maybe hard to design an example code to
show this problem. But I could show you one of different result I caught
from my program.
I tried to transform a multiline from lat/lng CRS to EPSG:3005 CRS, here is
the original data:
MULTILINESTRING ((117.182407 40.653277, 117.181545 40.653585, 117.181061
40.65376, 117.180523 40.653923))
the result on the 32-bit environment is:
MULTILINESTRING ((-5086316.771507925 6113285.390541192, -5086277.44327189
6113356.841506959, -5086255.136775202 6113396.941946386,
-5086233.7632936826113441.788309721))
the result on the 64-bit environment is:
MULTILINESTRING ((-5086316.771507925 6113285.390541192, -5086277.44327189
6113356.841506959, -5086255.136775202 6113396.941946386,
-5086233.7632936786113441.788309721))
pay attention to the red number, is different slightly. Because I use
multiline string to compute hashcode, so it may affect my final result
observably. And this problem is random and unexpected, so this uncertainty
will leave some danger in our program.
On Wed, Feb 15, 2012 at 2:14 PM, Ben Caradoc-Davies
<[email protected]> wrote:
> You should not need to remove libgcj; it is needed by some applications
> such as openoffice.
>
> Can you give a small example of the different behaviour you see in
> org.geotools.geometry.jts.JTS.**transform?
>
> I do not know if JTS uses strictfp to ensure exact portability of floating
> point operations:
> http://en.wikipedia.org/wiki/**Strictfp<http://en.wikipedia.org/wiki/Strictfp>
>
> Kind regards,
> Ben.
>
>
> On 15/02/12 14:06, Zheng Xudong wrote:
>
>> I have removed java-1.4.2-gcj-compat from Red Hat, and tried OpenJDK
>> 1.6.0 x64 and Oracle JDK 1.6/1.7 x64, but still have the problem, but the
>> same version of JDK on Ubuntu have no problem, the i586 JDK version on Red
>> Hat also have no problem.
>>
>> And I found there are some gcj related packages installed on the Red Hat:
>> libgcj-4.1.2-51.el5
>> libgcj-devel-4.1.2-51.el5
>> libgcj-devel-4.1.2-51.el5
>> libgcj-4.1.2-51.el5
>> libgcj-src-4.1.2-51.el5
>>
>> should I remove them all to solve the problem?
>>
>> On Wed, Feb 15, 2012 at 1:44 PM, Ben Caradoc-Davies<Ben.Caradoc-**
>> [email protected]> wrote:
>> What JRE/JDK are you using? Be very careful that you are not using gcj as
>> this is the default for some earlier Red Hat versions. gcj's behaviour
>> differs from the Oracle and OpenJDK implementations. gcj is *not* a
>> supported implementation for GeoTools. I think it is stuck at 1.5 and you
>> will also need 1.6 (Oracle or OpenJDK) for trunk and the upcoming 8.0.
>>
>> What do you get if at the command line you run:
>>
>> java -version
>>
>> Bad (gcj):
>> java version "1.5.0"
>> gij (GNU libgcj) version 4.6.1 20110908 (Red Hat 4.6.1-9)
>>
>> Good (OpenJDK):
>> java version "1.6.0_22"
>> OpenJDK Runtime Environment (IcedTea6 1.10.5)
>> (fedora-62.1.10.5.fc15-x86_64)
>> OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
>>
>> Good (Oracle)
>> java version "1.6.0_29"
>> Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
>> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)
>>
>> GeoTools runs fine in a 64-bit environment. 64-bit Java benefits from
>> -XX:+UseCompressedOops to improve memory footprint.
>>
>> Kind regards,
>> Ben.
>>
>>
>>
>> On 15/02/12 13:09, Zheng Xudong wrote:
>> Hi all,
>>
>> Recently, I encountered an odd problem when I run my program using
>> GeoTools (v8.0-M4) on 64-bit Java environment, the output of the same
>> program with the same input will different on different computer and even
>> different running. Then I carefully debug my program and finally found the
>> org.geotools.geometry.jts.JTS.**transform method on some 64-bit
>> environment will produce a little different result from the one on 32-bit
>> environment. The problem may be related to the computation accuracy. I
>> found the problem not happened on 64-bit Windows 7 and 64-bit Ubuntu, but
>> happened on the 64-bit RedHat Enterprise.
>>
>> I don't know the cause of the problem, and whether GeoTools could
>> running correctly on 64-bit environment. So I hope the developers would
>> give me some tips about that, and I suggest you to consider to design and
>> test GeoTools for 64-bit more.
>>
>> Thanks very much!
>>
>> --
>> 郑旭东
>> 北京航空航天大学计算机学院
>> 软件开发环境国家重点实验室
>>
>> Zheng Xudong
>> State Key Laboratory of Software Development Environment
>> School of Computer Science and Engineer, BeiHang University
>>
>>
>>
>> --
>> Ben Caradoc-Davies<Ben.Caradoc-**[email protected]>
>> Software Engineer
>> CSIRO Earth Science and Resource Engineering
>> Australian Resources Research Centre
>>
>>
>>
>> --
>> 郑旭东
>> 北京航空航天大学计算机学院
>> 软件开发环境国家重点实验室
>>
>> Zheng Xudong
>> State Key Laboratory of Software Development Environment
>> School of Computer Science and Engineer, BeiHang University
>>
>>
>>
> --
> Ben Caradoc-Davies <[email protected]>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Zheng Xudong
State Key Laboratory of Software Development Environment
School of Computer Science and Engineer, BeiHang University
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
GeoTools-GT2-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
