| Cast behaviour with Native types [message #1855535] |
Thu, 20 October 2022 01:39  |
|
The block of code below is intended to perform a file copy. Debug output shows that all three native types are correctly created, using concrete classes.
However, the copy operation fails to recognize the types.
var a = new Native("java.io.File")("a").toPath();
var b = new Native("java.io.File")("b").toPath();
var Files = Native("java.nio.file.Files");
Files.copy(a,b);
Invalid number (or types) of arguments for operation 'copy': expected 'java.io.InputStream, java.nio.file.Path, java.nio.file.CopyOption[]' but got 'org.eclipse.epsilon.eol.dom.NameExpression, org.eclipse.epsilon.eol.dom.NameExpression'
at (/home/jg/eclipse/epsilon-2-4/workspace/test/test.eol@8:0-8:16)
at (/home/jg/eclipse/epsilon-2-4/workspace/test/test.eol@8:0-8:16)
at (/home/jg/eclipse/epsilon-2-4/workspace/test/test.eol@1:0-8:16)
at (/home/jg/eclipse/epsilon-2-4/workspace/test/test.eol@1:0-8:16)
|
|
|
|
|
|
|
|
|
| Re: Cast behaviour with Native types [message #1855628 is a reply to message #1855627] |
Mon, 24 October 2022 10:51  |
|
Reason I am suggesting it is that Statement.execute()s behaviour will de hawkishly watched to be in line with the JLS spec, as there is so much reliance on that.
As it comes from the runtime, it will be in sync with the JLS in force for that runtime, which would be the intended behaviour. ('just like the Java I use.')
Reflection code tends to be fraught with risks, as it is really hard to test. So offloading responsibility and effort seems a sensible move.
|
|
|
Powered by
FUDForum. Page generated in 0.03214 seconds
] 
Search
Help
Register
Login
Home
