[jira] Commented: (COCOON-1790) VerifyException Attempt to split long or double on the stack in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12370191 ] Simone Gianni commented on COCOON-1790: --- Trying to understand what happens here (read: studying BCEL and BRAKES) i noticed that all new instructions are removed (in the rewrite method). I suppose they are moved somewhere somehow, and maybe that's the point where a check on the argument size is probabily missing, but i can't find where this happens. VerifyException Attempt to split long or double on the stack in javaflow -- Key: COCOON-1790 URL: http://issues.apache.org/jira/browse/COCOON-1790 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni When writing code like this : long time = System.currentTimeMillis(); Date date = new Date(time); the given exception is thrown. It's a validation exception. This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround : Date date = new Date(); date.setTime(time); but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter. I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution. The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1790) VerifyException Attempt to split long or double on the stack in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12369876 ] Simone Gianni commented on COCOON-1790: --- Yes, just tested with sun jdk under windows XP and got the same result. VerifyException Attempt to split long or double on the stack in javaflow -- Key: COCOON-1790 URL: http://issues.apache.org/jira/browse/COCOON-1790 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni When writing code like this : long time = System.currentTimeMillis(); Date date = new Date(time); the given exception is thrown. It's a validation exception. This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround : Date date = new Date(); date.setTime(time); but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter. I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution. The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1790) VerifyException Attempt to split long or double on the stack in javaflow
[ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12369000 ] Ugo Cei commented on COCOON-1790: - Did you try it with Sun's JDK as well? VerifyException Attempt to split long or double on the stack in javaflow -- Key: COCOON-1790 URL: http://issues.apache.org/jira/browse/COCOON-1790 Project: Cocoon Type: Bug Components: Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni When writing code like this : long time = System.currentTimeMillis(); Date date = new Date(time); the given exception is thrown. It's a validation exception. This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround : Date date = new Date(); date.setTime(time); but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter. I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine. Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution. The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
