android.os.Parcelable support

[James Wald]

One of the major pain points when using Lombok in Android projects is the fact that value classes almost always need to implement the android.os.Parcelable interface (http://developer.android.com/reference/android/os/Parcelable.html). This is Android's de-facto serialization mechanism, and it comes with a lot of fragile boilerplate. Every time the fields are changed, the implementation must change.

There's a fork of Lombok called Hrisey which adds the @Parcelable annotation (https://github.com/mg6maciej/hrisey/wiki/Parcelable). I'm curious what the Lombok team thinks about adding experimental support for this interface. I'd be up for the challenge if it's something the team would potentially consider adding.

-James

[Roel Spilker]

Android-specific annotations are welcome!

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

[Fabrizio Giudici]

On Thu, 18 Sep 2014 18:04:32 +0200, Roel Spilker <r.sp...@gmail.com>
wrote:

> Android-specific annotations are welcome!

+1


--
Fabrizio Giudici - Java Architect @ Tidalwave s.a.s.
"We make Java work. Everywhere."
http://tidalwave.it/fabrizio/blog - fabrizio...@tidalwave.it

[James Wald]

Thanks! I'll take a stab at it this.

--
You received this message because you are subscribed to a topic in the Google Groups "Project Lombok" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/project-lombok/DZvMfm7MFOg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to project-lombok+unsubscribe@googlegroups.com.

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

--

James

[James Wald]

I've been hacking on this for a bit and I noticed that the package tests are failing because Android APIs aren't on the classpath. I think a reasonable approach would be to stub the necessary packages / APIs for the tests. Is this something you might normally do?

Another thing I was thinking about is the fact that we normally have to consider the target API level when calling Android APIs, as older devices may not actually have the API being called. Luckily android.os.Parcel and android.os.Parcelable haven't changed since API level 1 so that won't be a problem in this case.

-James

[Roel Spilker]

Yes, to compile we've created some stub files that only contain the used method signatures and fields.

Alternatively, we could depend on a jar file if one is legally available.

Roel

--

You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.

[James Wald]

The jar for Android 4.1.1.4 is in Maven Central so we can depend on that. It isn't the latest and greatest (which would be 4.4) but has everything that I'll need for @Parcelable. Google stopped pushing to Central a while ago, requiring developers to rely on a local m2 repository that is managed by the Android SDK tools.

You received this message because you are subscribed to a topic in the Google Groups "Project Lombok" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/project-lombok/DZvMfm7MFOg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to project-lombo...@googlegroups.com.

[James Wald]

To clarify, Google never actually published those artifacts, it was done by the community (see https://code.google.com/p/android/issues/detail?id=4577). Many open source Android projects depend on that 4.1.1.4 artifact, including various high-profile projects from Square. I think it's okay to do so here too as long as those jars aren't redistributed in the Lombok artifacts.

[Roel Spilker]

In that case you can just add the dependency in the build scripts.

[Maciej Górski]

Hello guys,

I'm a maintainer of Hrisey fork and glad to see there is some interest in adding Android specific annotations to Lombok. I actually didn't think it would make sense to add these annotations, becasue Lombok's annotations are mostly solving issues with Java's verbosity and annotations I created are fighting Android SDK's issues. It's like adding annotations for Spring, EJB or whatever.

The current state of the fork is that I didn't write Eclipse versions of the processor, because I simply don't use it and when I ask someone it's only like 5% of people still use it for Android apps development. However if there is anyone interested in "cloning" support from javac, I would really appreciate it.

@James
About the failing during tests, I had the same issue, but I simply put android.jar in /lib/test, so it's not bundled into the final jar file.
I would be happy to collaborate and put Android related annotations back into Lombok.

Btw. Roel & Reiner: you made it insanely easy to add new annotations. Thanks!

[Reinier Zwitserloot]

Does the Hrisey fork add support for intellij then?

At any rate, we have the 'extern' package specifically for annotations that help you fight boilerplate when working with libraries. lombok.extern.android doesn't exist (yet!) but it would fit perfectly well within the lombok 'charter', so to speak.

NB: because we use ant/ivy, it is fairly simple to add a dependency based on a URL that hosts the artifact in question. We actually use this for some exotic deps that don't have (good) versions available in maven central. We don't see any particular issue with hosting this dep on our servers, assuming it is legal to do so. In other words, we can stick with the 4.1 in maven central for now, and if there's ever a need to upgrade due to a new variant of Parcelable coming out, we have a way to do that.

But, stubbing out just the required API is fine too. More convenient, really. If you've already done that, let's stick with it.

[Maciej Górski]

Yes, I also forked Michail's lombok-intellij-plugin to add support for Android-specific annotations.
I'll copy my @Parcelable processor into an appropriate package and add 4.1 dependency. If you can just point out where in the build file I can add it, that would be helpful.

[Maciej Górski]

Hey,

I have a couple of issues with my code not working with JDK 8.

These is what I already fixed:
- replaced call to JCClassDecl.getExtendsClause with Javac.getExtendsClause(JCClassDecl), solving compilation issue
- replaced access to Type.tag with Type.getKind for primitives or Type instanceof ClassType/ArrayType, also solving compilation issue
- for paramter variable definitions called JavacTreeMaker.Modifiers with Flags.PARAMETER instead of 0, the error was "junit.framework.AssertionFailedError: Method parameter without PARAMETER flag"

Now I'm facing an error I cannot understand:

    [junit] Value of x -1
    [junit] junit.framework.AssertionFailedError: Value of x -1
    [junit]     at com.sun.tools.javac.util.Assert.error(Assert.java:133)
    [junit]     at com.sun.tools.javac.util.Assert.check(Assert.java:94)
    [junit]     at com.sun.tools.javac.util.Bits.incl(Bits.java:186)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.initParam(Flow.java:1796)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitMethodDef(Flow.java:1749)
    [junit]     at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitMethodDef(Flow.java:2507)
    [junit]     at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:772)
    [junit]     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    [junit]     at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitClassDef(Flow.java:1705)
    [junit]     at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:2486)
    [junit]     at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
    [junit]     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    [junit]     at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.visitClassDef(Flow.java:1677)
    [junit]     at com.sun.tools.javac.comp.Flow$AssignAnalyzer.visitClassDef(Flow.java:2486)
    [junit]     at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:687)
    [junit]     at com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:49)
    [junit]     at com.sun.tools.javac.comp.Flow$BaseAnalyzer.scan(Flow.java:389)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.scan(Flow.java:1367)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.analyzeTree(Flow.java:2370)
    [junit]     at com.sun.tools.javac.comp.Flow$AbstractAssignAnalyzer.analyzeTree(Flow.java:2353)
    [junit]     at com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:210)
    [junit]     at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1325)
    [junit]     at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1289)
    [junit]     at lombok.delombok.Delombok.callFlowMethodOnJavaCompiler(Delombok.java:568)
    [junit]     at lombok.delombok.Delombok.delombok(Delombok.java:506)
    [junit]     at lombok.RunTestsViaDelombok.transformCode(RunTestsViaDelombok.java:52)
    [junit]     at lombok.AbstractRunTests.compareFile(AbstractRunTests.java:78)
    [junit]     at lombok.DirectoryRunner.runTest(DirectoryRunner.java:142)
    [junit]     at lombok.DirectoryRunner.run(DirectoryRunner.java:127)

Have you even seen something like this? Any pointers maybe?

Thanks in advance,
M.

When I'm done with this, no new assertion error appears and maybe a bit of refactoring, because the code is somewhat ugly, I could send you a pull request for @Parcelable.

[Maciej Górski]

Do you have any clue about this issue?

[Reinier Zwitserloot]

We're open for push requests on this. As long as the annotation is in package lombok.extern.android or some such, we'll have a look at it. Extra credits of course if there's an appropriate entry on the features page in the website directory. Roel even does some occasional android hacking so he can test it and everything.

 --Reinier Zwitserloot

[Maciej Górski]

Hey,

I'd be happy to add `Parcelable` support to Lombok.

Changing package name is not an issue. It would be bad not to change it to something like `lombok.extern.android`, because I constantly sync with Lombok and that could mean more merge conflicts than necessary.

I'm totally blocked on the issue my code doesn't work on JDK 8, with a cryptic error message `Value of x -1`. I wrote about it in one of my previous posts.
Have you ever encounter such error when developing other annotation processors?

Cheers,
Maciej

[Aravind S]

Hi,

Is there any update to support Parcelable annotation in lombok?