1. 24 Mar, 2014 1 commit
  2. 22 Mar, 2014 5 commits
  3. 21 Mar, 2014 3 commits
  4. 21 Feb, 2014 2 commits
  5. 17 Feb, 2014 3 commits
  6. 10 Feb, 2014 3 commits
  7. 16 Jan, 2014 2 commits
  8. 14 Jan, 2014 4 commits
  9. 13 Jan, 2014 6 commits
  10. 10 Jan, 2014 3 commits
    • Max Cai's avatar
      Correctness: floating point equality using bits instead of ==. · 79b311c1
      Max Cai authored
      Special values for float and double make it inaccurate to test the equality with ==.
      The main Java library uses the standard Object.equals() implementation for all fields,
      which for floating point fields means Float.equals() or Double.equals(). They define
      equality as bitwise equality, with all NaN representations normalized to the same bit
      sequence (and therefore equal to each other). This test checks that the nano
      implementation complies with Object.equals(), so NaN == NaN and +0.0 != -0.0.
      
      Change-Id: I97bb4a3687223d8a212c70cd736436b9dd80c1d7
      79b311c1
    • Max Cai's avatar
      Don't serialize required fields whose 'has' flags are unset. · 1b1735ce
      Max Cai authored
      Change-Id: Ibbe944fff83e44a8f2206e18ee9ec6f10661297a
      1b1735ce
    • Max Cai's avatar
      Extension overhaul. · e3714f00
      Max Cai authored
      - Get rid of TypeLiteral<T>. It was introduced to read the component
        type of a List<T> at runtime. But we use arrays everywhere else,
        and we can always read the component type of an array type at
        runtime.
      - Properly read/write "minor" types (e.g. sint32, sfixed32). The old
        implementation could only read/write data as the "typical" types
        (one per Java type), e.g. java.lang.Integer -> int32, java.lang.Long
        -> int64. So if e.g. an extension specifies sfixed32 as the type, it
        would be read/written in the totally incompatible int32 format.
      - Properly serialize repeated packed fields. The old implementation
        doesn't do packed serialization. As an added bonus, and to be more
        aligned with the rest of protobuf nano / main, repeated packable
        extensions can deserialize both packed and non-packed data.
      - Split Extension class into a hierarchy so under typical usage a
        large chunk of code dealing with primitive type extensions can be
        removed by ProGuard.
      
      Bug: https://code.google.com/p/android/issues/detail?id=62586
      Change-Id: I0d692f35cc2a8ad3a5a1cb3ce001282b2356b041
      e3714f00
  11. 19 Dec, 2013 3 commits
  12. 12 Dec, 2013 1 commit
    • Andrew Flynn's avatar
      Fix MessageNanoPrinter for accessors · 02a9ea00
      Andrew Flynn authored
      accessors mode switches proto fields away from being public fields (which is
      how MessageNanoPrinter found which fields to print via reflection). Add a
      pass through the methods looking for generated accessor methods to print
      those as well.
      
      Change-Id: I7c47853ecbd5534086f44b25a89dbbe56f63ed03
      02a9ea00
  13. 10 Dec, 2013 4 commits
    • Max Cai's avatar
      am 6b9d96b2: am 3f9bd998: Merge "Avoid class initializers to help ProGuard." · 56c47ec7
      Max Cai authored
      * commit '6b9d96b2a3b32c141e2b105fcfde4f4b0dfae3f5':
        Avoid class initializers to help ProGuard.
      56c47ec7
    • Max Cai's avatar
      am 3f9bd998: Merge "Avoid class initializers to help ProGuard." · 75c5216b
      Max Cai authored
      * commit '3f9bd9989c79db575b83e2f96b48c695f30ca153':
        Avoid class initializers to help ProGuard.
      75c5216b
    • Max Cai's avatar
      b3bc6095
    • Max Cai's avatar
      Avoid class initializers to help ProGuard. · 04feb76f
      Max Cai authored
      Class initializers prevent ProGuard from inlining any methods
      because it thinks the class initializer may have side effects.
      This is true for static methods, but instance methods can still
      be inlined, because to have an instance you will have touched
      the class and any class initializers would have run. But
      ProGuard only starts inlining instance methods of classes with
      class initializers from v4.11b6, and Android uses v4.4 now.
      
      This change tries to avoid the class initializers as much as
      possible, by delaying the initialization of the empty array and
      some fields' saved defaults until when they're needed. However,
      if the message hosts any extensions, they must be public static
      final and therefore introducing the class initializer. In that
      case we won't bother with lazy initialization.
      
      Change-Id: I00d8296f6eb0023112b93ee135cdb28dbd52b0b8
      04feb76f