jboolean vs. boolean

[fire...@squareup.com]

J2ObjC uses typedefs for all scalar types (http://j2objc.org/docs/Translation-Reference.html#types). For example, it uses "jboolean" rather than "boolean", although they are functionally equivalent.

IMO this hurts usability as ObjC/Swift programmers have to keep two different type sets in mind, as well as the conversions between them. What was the reasoning behind using these typedefs rather than using the types that they reference directly?

Is this something that is open for rethinking, or at least something where a flag could be added to disable it?

Thanks!

[Matt Campbell]

I agree; I think it would be better to use BOOL, NSInteger, etc. Since
J2ObjC provides its own jni.h, it can define the JNI types as synonyms
for the usual ObjC/Cocoa types.

Matt

[Tom Ball]

That doesn't work in practice because none of the iOS architectures define primitive types the same way Java does. BOOL can be a signed int (C bool) on 64-bit iOS, but otherwise is a signed char, "int" can be 4 bytes or 8 bytes, etc. We moved to "j" primitive types after fixing several arch-incompatibilities (there were lots of 64-bit issues), realizing that when Java references a primitive type, it can only have a specific definition regardless of architecture. That's not a Java bug, but one reason it's so portable -- specified types were controversial when it first released, until developers saw all the arch-related pain they had with C/C++ disappear.

Get Apple and LLVM to standardize on Java's definitions of these types, and we'll happily go back. :-)

--
You received this message because you are subscribed to the Google Groups "j2objc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to j2objc-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Campbell]

Thanks for the explanation. That makes sense. For me, the use of JNI
types in the generated ObjC headers just looked a little weird; it
wasn't a problem.

Matt

On 3/16/2016 3:22 PM, 'Tom Ball' via j2objc-discuss wrote:
> That doesn't work in practice because none of the iOS architectures
> define primitive types the same way Java does. BOOL can be a signed int
> (C bool) on 64-bit iOS, but otherwise is a signed char, "int" can be 4
> bytes or 8 bytes, etc. We moved to "j" primitive types after fixing
> several arch-incompatibilities (there were lots of 64-bit issues),
> realizing that when Java references a primitive type, it can only have a
> specific definition regardless of architecture. That's not a Java bug,
> but one reason it's so portable -- specified types were controversial
> when it first released, until developers saw all the arch-related pain
> they had with C/C++ disappear.
>
> Get Apple and LLVM to standardize on Java's definitions of these types,
> and we'll happily go back. :-)
>
> On Wed, Mar 16, 2016 at 12:56 PM Matt Campbell <mattca...@pobox.com
> <mailto:mattca...@pobox.com>> wrote:
>
> I agree; I think it would be better to use BOOL, NSInteger, etc. Since
> J2ObjC provides its own jni.h, it can define the JNI types as synonyms
> for the usual ObjC/Cocoa types.
>
> Matt
>
> On 3/16/2016 2:47 PM, fire...@squareup.com

> <mailto:fire...@squareup.com> wrote:
> > J2ObjC uses typedefs for all scalar types
> (http://j2objc.org/docs/Translation-Reference.html#types). For
> example, it uses "jboolean" rather than "boolean", although they are
> functionally equivalent.
> >
> > IMO this hurts usability as ObjC/Swift programmers have to keep
> two different type sets in mind, as well as the conversions between
> them. What was the reasoning behind using these typedefs rather than
> using the types that they reference directly?
> >
> > Is this something that is open for rethinking, or at least
> something where a flag could be added to disable it?
> >
> > Thanks!
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "j2objc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to j2objc-discus...@googlegroups.com

> <mailto:j2objc-discuss%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google
> Groups "j2objc-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to j2objc-discus...@googlegroups.com

> <mailto:j2objc-discus...@googlegroups.com>.

[fire...@squareup.com]

On Wednesday, March 16, 2016 at 1:22:43 PM UTC-7, Tom Ball wrote:
> That doesn't work in practice because none of the iOS architectures define primitive types the same way Java does. BOOL can be a signed int (C bool) on 64-bit iOS, but otherwise is a signed char, "int" can be 4 bytes or 8 bytes, etc. We moved to "j" primitive types after fixing several arch-incompatibilities (there were lots of 64-bit issues), realizing that when Java references a primitive type, it can only have a specific definition regardless of architecture. That's not a Java bug, but one reason it's so portable -- specified types were controversial when it first released, until developers saw all the arch-related pain they had with C/C++ disappear.
>
>
> Get Apple and LLVM to standardize on Java's definitions of these types, and we'll happily go back. :-)

I agree the 32-bit vs. 64-bit differences in Foundation are aggravating, but there are still stable types which are part of the standard Darwin POSIX implementation, such as uint32_t (http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html). Using these should provide stability while still removing the dependence on a whole new type set for Objective-C programmers using J2ObjC.