On 03/11/2017 12:17 AM, Patrick wrote:
Please to announce:
A new version of JavacTo available for download. Version 1.1
* Updated JavacToD visitor. Almost 100% parsing success with dscanner
and JDK package subset (see results below).
* Updated JavacToJava visitor.
* Source and Target Text pane mouse click integration with List and Tree
views. Click in a text pane and the list and tree view will update with
the related visitor node. Very cool.
* New search capabilities. Text and Tree.Kind search.
* Support for command line translation (non-UI, very fast).
* Target highlighting is now automatic (matches java source
highlighting). No need to add code to highlight. In fact, manually
highlighting code is discouraged.
* Process dialog when reading large .zip/.jar files.
* Other UI enhancements.
Results with dscanner:
Package Total files Failed
java.util 362 15
java.math 8 1
java.net 78 0
java.nio 126 1
java.io 83 0
java.lang 219 4
Success is attributed to dscanner providing no output when parsing a file.
Failures are all attributed error output from:
* Java’s hybrid enum definition. (Which I believe will take a D enum and
custom class to implement.)
* Java’s lambda method definition.
Successful parsing with dscanner I believe is a major milestone for
JavacTo. This suggests a good percentage of java code can be
automatically translated to D. Clearly this is not a definitive
statement just yet, but an encouraging move in the right direction.
Dscanner can now be used to format the JavacToD generated code for code
review. And <gasp!> critique the quality of the code generated (or
worse, the quality of the java code :).
It’s clear the next step is to successfully compile the code. With
effort working towards a successful compile, there's no doubt more
changes are in store for the JavacToD visitor code. In addition, I’m
anticipating some hand editing of the generated code will be required
while other code will be thrown out. Perhaps helper code will be
warranted as well. In any case, we'll see where the compiler takes us as
we work towards a weighted balance of auto-generated code to hand
editing. Anyway, to be clear, the current objective (hope) is to create
a D library based on java JDK subset listed above (or something close to
it). This library can then be used as the bases for translating other
open source java projects to D.
So… more work to be done.
Could you instead side-track and create JNI bindings instead?
This would be a massive help for Android.