Changes between Version 148 and Version 149 of j2p


Ignore:
Timestamp:
10/17/24 10:01:21 (2 weeks ago)
Author:
wouter
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • j2p

    v148 v149  
    136136This approach ignores the more recent Python Enum class. This new approach is incompatible with the traditional approach, it gives an extra layer of indirection, it does not allow the custom constructors that we need, it is very complex, and all this complicates our translation job.
    137137
     138
     139
    138140=== Auto Boxing
    139141Autoboxing is the automatic conversion that the Java compiler makes between the primitive types and their corresponding object wrapper classes. For example, converting an int to an Integer, a double to a Double, and so on. If the conversion goes the other way, this is called unboxing.
    140142
    141 The translator currently does not support auto boxing. That means you will get an error on the python side if you for instance do this on the java side
    142 
     143{{{
     144boolean b=false;
     145List<Boolean> l=new ArrayList<>();
     146l.add(b);
     147}}}
     148
     149Here in line 3 the b is auto-boxed from boolean to Boolean.
     150In many cases, this is no problem, because python has no equivalent objects for primitive types, so there are no 2 variants of boolean, float, str. So both int and Integer are translated to python int anyway.
     151
     152But keep reading, the automatic casting is closely related and is more problematic.
     153
     154=== Implicit casting, narrowing
     155Java does automatic casting to silently convert between bytes, int, long etc. These can involve narrowing, widening, and potentially lead to conversions or loss of precision etc. There is partial support for these. The translator recognises when such conversion is done and tries to insert extra code to implement the expected narrowing as needed. But the specification has lots of special cases and the implementation is partial.
     156
     157The translator does recognise differences between left and right side in assignments and tries to cast properly. Eg,
     158{{{
     159Float x=3
     160}}}
     161
     162it will recognise the right side of the assignment is an int, and convert it to float before assigning into the x. Note that python itself will not give any warning on type errors, this would be fine in python
     163{{{
     164x:float=3
     165}}}
     166
     167but it would be wrong as x now will contain an int (regardless of the type hint).
     168
     169A more tricky case is this
     170{{{
     171Float f = Float.valueOf(3);
     172}}}
     173
     174The call argument, an integer, is in java automatically cast to a float, because that's the actual type required by valueOf. The translator currently does not recognise this case.
     175
     176Another example:
    143177{{{
    144178int n=1;
     
    146180}}}
    147181
    148 You will have to call an explicit converter, typically toString(), on the arguments that need to be converted into the proper argument type.
     182Java will automatically (1) convert n to Integer (2) call toString. Currently, in this special case (+ operator) the translator does not support either, so you will have to do both yourself. eg write in java
     183{{{
     184return "number "+ ((Integer)n).toString();
     185}}}
    149186
    150187
     
    169206All these complications around varargs, including more eg [https://github.com/mrocklin/multipledispatch/issues/72 around dispatching vararg-typed methods] led us to currently not support varargs.
    170207
    171 === Implicit casting, narrowing
    172 Java does automatic casting to silently convert between bytes, int, long etc. These can also involve narrowing, loss of precision etc. There is partial support for these. The translator recognises when such conversion is done and tries to insert extra code to implement the expected narrowing as needed. But the specification has lots of special cases and the implementation is partial.
    173208
    174209=== @NonNull