You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Laurent Medioni <lm...@odyssey-group.com> on 2009/06/15 15:40:59 UTC
Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Should we also replace, in Cocoon 2.1.x, JDT 3.1 with 3.5 ?
As 3.1 does not know about 1.6 and 3.5 still support Java 1.1 ;)
We use 3.5 since a few weeks and have not detected any issue...
Laurent
-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: lundi, 31. août 2009 22:45
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
El 31/08/09 04:54, Laurent Medioni escribió:
> Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
>
+1 Would you provide a patch. I think it should not be too dificult.
BTW, The java 1.3 was set to default value, due historical reasons.
Perhaps it is time to switch that too. :)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Should we also replace, in Cocoon 2.1.x, JDT 3.1 with 3.5 ?
As 3.1 does not know about 1.6 and 3.5 still support Java 1.1 ;)
We use 3.5 since a few weeks and have not detected any issue...
Laurent
-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: lundi, 31. août 2009 22:45
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
El 31/08/09 04:54, Laurent Medioni escribió:
> Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
>
+1 Would you provide a patch. I think it should not be too dificult.
BTW, The java 1.3 was set to default value, due historical reasons.
Perhaps it is time to switch that too. :)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with
a 1.6 JVM and using the Eclipse compiler
Posted by Antonio Gallardo <ag...@agssa.net>.
El 31/08/09 04:54, Laurent Medioni escribió:
> Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
>
+1 Would you provide a patch. I think it should not be too dificult.
BTW, The java 1.3 was set to default value, due historical reasons.
Perhaps it is time to switch that too. :)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hi Antonio,
I am just trying to understand what is done in EclipseJavaCompiler ;)
Original code: if we have the compiler-compliance-level parameter set to 1.5, then the JDT options org.eclipse.jdt.core.compiler.compliance and org.eclipse.jdt.core.compiler.source are set to 1.5. Then SystemUtils.JAVA_VERSION_INT is used to set the JDT option org.eclipse.jdt.core.compiler.codegen.targetPlatform.
So if I use a 1.6 JVM and if I set compiler-compliance-level to 1.5 (maximum handled by JDT 3.1) then I end up with the following combination out of EclipseJavaCompiler:
- compliance = 1.5
- source = 1.5
- targetPlatform = 1.3
It is true that this combination is discouraged in the Eclipse Preferences panel. It requires that Source compatibility <= Classfile compatibility (targetPlatform) <= Compliance level.
But with my "wrong" configuration I get no errors from JDT and XSPs are compiled and are running correctly (which is "understandable" because my target platform is a 1.6, so the minimum level of 1.3 is respected).
Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
Laurent
-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: vendredi, 28. août 2009 17:51
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Hi Laurent,
Hmm. I am wondering about your message, because IIRC, the compliance
level almost define the target java version for compiled class. I mean
if I select compliance level 1.5, the generated class cannot be compiled
for java 1.3 because 1.3 JVM cannot handle some of the new features
introduced in java 1.5. I can be wrong be I can recall it is not
possible to set that way in eclipse. I mean a higher compliance level
(ie: 1.5) and a lower compilation level (ie: 1.3). It simply does not work.
Best Regards,
Antonio Gallardo.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with
a 1.6 JVM and using the Eclipse compiler
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Laurent,
Hmm. I am wondering about your message, because IIRC, the compliance
level almost define the target java version for compiled class. I mean
if I select compliance level 1.5, the generated class cannot be compiled
for java 1.3 because 1.3 JVM cannot handle some of the new features
introduced in java 1.5. I can be wrong be I can recall it is not
possible to set that way in eclipse. I mean a higher compliance level
(ie: 1.5) and a lower compilation level (ie: 1.3). It simply does not work.
Best Regards,
Antonio Gallardo.
El 28/08/09 01:27, Laurent Medioni escribió:
> Hi,
> Yes I used it, but it only affects the compliance level, not the generated class file compatibility, which is directly taken from the version of the running JVM... And the default of the switch/case is 1.3...
> So I had to replace the 2 switch/cases in EclipseJavaCompiler (1 for the source code version and 1 for the target version) with new ones defaulting to 1.5 if the version is greater than 1.5.
> So using JDT 3.1 and running a 1.6 JVM produces 1.5 code (which is the limit of JDT 3.1).
>
> My second try has been to use JDT 3.5 and modifying again EclipseJavaCompiler to properly manage 1.6. And everything seems to work fine.
>
> Laurent
>
> ________________________________________
> From: Antonio Gallardo [mailto:agallardo@agssa.net]
> Sent: jeudi, 27. août 2009 23:37
> To: users@cocoon.apache.org
> Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
>
> Hi Laurent,
>
> Please look into the cocoon.xconf for the configuration of eclipse compiler and set the value to "1.5" instead of "auto". Here is the code:
> <!--+
> 55 :
>
>
> | Specifies the java code source version used to compile the XSP code.
> 56 :
>
>
> |
> 57 :
>
>
> | Posible values:
> 58 :
>
>
> | 1.3 = Java version 1.3
> 59 :
>
>
> | 1.4 = Java version 1.4
> 60 :
>
>
> | 1.5 = Java version 1.5
> 61 :
>
>
> | auto = The version of the JVM where cocoon is running. (Default value).
> 62 :
>
>
> |
> 63 :
>
>
> | NOTE: The parameter is optional to keep backward compatibility.
> 64 :
> anathaniel
> 555089
> | The parameter works with Sun Javac compiler and the Eclipse compiler.
> 65 :
> antonio
> 124779
> | The pizza compiler does not support java 1.5.
> 66 :
>
>
> +-->
> 67 :
>
>
> <!--<parameter name="compiler-compliance-level" value="auto"/> -->
>
> Best Regards,
>
> Antonio Gallardo
>
>
>
> ____________________________________________________________
>
> � This email and any files transmitted with it are CONFIDENTIAL and intended
> solely for the use of the individual or entity to which they are addressed.
> � Any unauthorized copying, disclosure, or distribution of the material within
> this email is strictly forbidden.
> � Any views or opinions presented within this e-mail are solely those of the
> author and do not necessarily represent those of Odyssey Financial
> Technologies SA unless otherwise specifically stated.
> � An electronic message is not binding on its sender. Any message referring to
> a binding engagement must be confirmed in writing and duly signed.
> � If you have received this email in error, please notify the sender immediately
> and delete the original.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hi,
Yes I used it, but it only affects the compliance level, not the generated class file compatibility, which is directly taken from the version of the running JVM... And the default of the switch/case is 1.3...
So I had to replace the 2 switch/cases in EclipseJavaCompiler (1 for the source code version and 1 for the target version) with new ones defaulting to 1.5 if the version is greater than 1.5.
So using JDT 3.1 and running a 1.6 JVM produces 1.5 code (which is the limit of JDT 3.1).
My second try has been to use JDT 3.5 and modifying again EclipseJavaCompiler to properly manage 1.6. And everything seems to work fine.
Laurent
________________________________________
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: jeudi, 27. août 2009 23:37
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Hi Laurent,
Please look into the cocoon.xconf for the configuration of eclipse compiler and set the value to "1.5" instead of "auto". Here is the code:
<!--+
55 :
| Specifies the java code source version used to compile the XSP code.
56 :
|
57 :
| Posible values:
58 :
| 1.3 = Java version 1.3
59 :
| 1.4 = Java version 1.4
60 :
| 1.5 = Java version 1.5
61 :
| auto = The version of the JVM where cocoon is running. (Default value).
62 :
|
63 :
| NOTE: The parameter is optional to keep backward compatibility.
64 :
anathaniel
555089
| The parameter works with Sun Javac compiler and the Eclipse compiler.
65 :
antonio
124779
| The pizza compiler does not support java 1.5.
66 :
+-->
67 :
<!-- <parameter name="compiler-compliance-level" value="auto"/> -->
Best Regards,
Antonio Gallardo
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with
a 1.6 JVM and using the Eclipse compiler
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Laurent,
Please look into the cocoon.xconf for the configuration of eclipse
compiler and set the value to "1.5" instead of "auto". Here is the code:
<!--+
55 : | Specifies the java code source version used to compile the XSP
code.
56 : |
57 : | Posible values:
58 : | 1.3 = Java version 1.3
59 : | 1.4 = Java version 1.4
60 : | 1.5 = Java version 1.5
61 : | auto = The version of the JVM where cocoon is running.
(Default value).
62 : |
63 : | NOTE: The parameter is optional to keep backward compatibility.
64 : anathaniel 555089
<http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/conf/xsp-program-language.xconf?view=diff&pathrev=555089&r1=555088&r2=555089>
| The parameter works with Sun Javac compiler and the Eclipse compiler.
65 : antonio 124779
<http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/conf/xsp-program-language.xconf?view=diff&pathrev=555089&r1=124778&r2=124779>
| The pizza compiler does not support java 1.5.
66 : +-->
67 : <!-- <parameter name="compiler-compliance-level" value="auto"/> -->
Best Regards,
Antonio Gallardo
El 21/08/09 09:27, Laurent Medioni escribió:
> Hello,
> Still with our Cocoon 2.1.11 on a 1.6 JVM series...
> Just noticed that org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler does not know anything about 1.6 (nothing wrong with this as it uses JDT 3.1) but in this case defaults to... 1.3, which is quite a big step back from 1.4 ;).
> It is possible to force the compliance level to 1.5 through the xconf parameter compiler-compliance-level but no configuration is possible for the generated class file compatibility, which does not obey to the same parameter...
>
> I tried to replace JDT 3.1 by the latest 3.5 and locally patched EclipseJavaCompiler to manage a 1.6 value... For the moment it works well...
>
> Cheers,
> Laurent
>
> ____________________________________________________________
>
> � This email and any files transmitted with it are CONFIDENTIAL and intended
> solely for the use of the individual or entity to which they are addressed.
> � Any unauthorized copying, disclosure, or distribution of the material within
> this email is strictly forbidden.
> � Any views or opinions presented within this e-mail are solely those of the
> author and do not necessarily represent those of Odyssey Financial
> Technologies SA unless otherwise specifically stated.
> � An electronic message is not binding on its sender. Any message referring to
> a binding engagement must be confirmed in writing and duly signed.
> � If you have received this email in error, please notify the sender immediately
> and delete the original.
>
Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hello,
Still with our Cocoon 2.1.11 on a 1.6 JVM series...
Just noticed that org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler does not know anything about 1.6 (nothing wrong with this as it uses JDT 3.1) but in this case defaults to... 1.3, which is quite a big step back from 1.4 ;).
It is possible to force the compliance level to 1.5 through the xconf parameter compiler-compliance-level but no configuration is possible for the generated class file compatibility, which does not obey to the same parameter...
I tried to replace JDT 3.1 by the latest 3.5 and locally patched EclipseJavaCompiler to manage a 1.6 value... For the moment it works well...
Cheers,
Laurent
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hello,
Still with our Cocoon 2.1.11 on a 1.6 JVM series...
Just noticed that org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler does not know anything about 1.6 (nothing wrong with this as it uses JDT 3.1) but in this case defaults to... 1.3, which is quite a big step back from 1.4 ;).
It is possible to force the compliance level to 1.5 through the xconf parameter compiler-compliance-level but no configuration is possible for the generated class file compatibility, which does not obey to the same parameter...
I tried to replace JDT 3.1 by the latest 3.5 and locally patched EclipseJavaCompiler to manage a 1.6 value... For the moment it works well...
Cheers,
Laurent
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Fix now promised for IBM Java Runtimes 6.0 SR6.
-----Original Message-----
From: Laurent Medioni [mailto:lmedioni@odyssey-group.com]
Sent: lundi, 15. juin 2009 15:41
To: users@cocoon.apache.org
Cc: dev@cocoon.apache.org
Subject: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Fix now promised for IBM Java Runtimes 6.0 SR6.
-----Original Message-----
From: Laurent Medioni [mailto:lmedioni@odyssey-group.com]
Sent: lundi, 15. juin 2009 15:41
To: users@cocoon.apache.org
Cc: dev@cocoon.apache.org
Subject: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.