New version of JavacTo available.

[rikki cattermole]

On 03/11/2017 12:17 AM, Patrick wrote:
> Please to announce:
> 
> A new version of JavacTo available for download. Version 1.1
> https://sourceforge.net/projects/javacto/
> 
> 
> Features:
> * 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.
> 
> Patrick

Could you instead side-track and create JNI bindings instead?
This would be a massive help for Android.