Generate java bindings for constants.

mojo/not-to-commit/java_mojo/mojo_public_test_interfaces/src/org/chromium/mojo/bindings/test/sample/SampleServiceConstants.java

Index: mojo/not-to-commit/java_mojo/mojo_public_test_interfaces/src/org/chromium/mojo/bindings/test/sample/SampleServiceConstants.java
diff --git a/mojo/not-to-commit/java_mojo/mojo_public_test_interfaces/src/org/chromium/mojo/bindings/test/sample/SampleServiceConstants.java b/mojo/not-to-commit/java_mojo/mojo_public_test_interfaces/src/org/chromium/mojo/bindings/test/sample/SampleServiceConstants.java
new file mode 100644
index 0000000000000000000000000000000000000000..67804005ee0e28a74b4abc2195c53968360a4b5d
--- /dev/null
+++ b/mojo/not-to-commit/java_mojo/mojo_public_test_interfaces/src/org/chromium/mojo/bindings/test/sample/SampleServiceConstants.java
@@ -0,0 +1,20 @@
+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// This file is autogenerated by:
+//     mojo/public/tools/bindings/mojom_bindings_generator.py
+// For:
+//     mojo/public/interfaces/bindings/tests/sample_service.mojom
+//
+
+package org.chromium.mojo.bindings.test.sample;

[rmcilroy, 2014/05/20 12:43:29]

I don't really like the idea of needing a separate class for constants within a
mojom file.  I can see from the previous CL there was discussion over whether a
mojo module is a Class or package, and if it is a package I realize we need a
separate class for outer constants.

I chatted with Marcus this morning as to whether mojo modules should be packages
or classes, and there seem to be pros and cons to either side - as I see it:
  package:
    + clearer separation of implementation for individual structs / interfaces
    + similar to CPP bindings where a module is a namespace
    - requires Constants class for outer constants in mojom
    - if inner mojom structs/interfaces have the same name, then classes which
use these generated bindings end up having to fully specify the package/class to
differentiate (e.g., org.chromium.mojo.bindings.test.sample.Foo vs 
org.chromium.mojo.bindings.test.other_sample.Foo).

  class:
    + no need for outer Constants class
    + inner mojom structs/interfaces can always be differentated via the outer
class name - e.g., Sample.Foo v.s. OtherSample.Foo)
    - potential for massive genrated implementation classes which make it
difficult to read through generated code (thought this seems similar to the CPP
binding generator).
    - semantically it seems to make more sense for a mojo module to correspond a
Java package

I can't really see a clear advantage one way or another, so I'm kindof agnostic
to whichever is choosen, but wanted to start the debate here in case there is
any better ideas we haven't thought of.  

Tommy: Marcus mentions you did a lot of work with the protobuf generators for
Sync - did you encounter any similar issues and how are they solved in protobuf?
 

[qsr, 2014/05/20 13:12:45]

 Well, I do not have a strong opinion either. I started with one file per mojom,
because it seemed to be that it would be easier to identify generated code that
way. Marcus seemed to be in favor of one class per entity, so I changed.

[rmcilroy, 2014/05/22 15:52:07]

Given what you mention below with different mojom files being able define the
same mojo module, then I am now definitely in support of each mojo module being
a package rather than a Class.  I still don't like the idea of having a separate
Constants file, however I've sent an email to the mojo mailing list asking
whether we even need the concept of module level constants - they don't seem to
be used anywhere currently and if they aren't required then this would avoid
this issue entirely.

+
+public final class SampleServiceConstants {

[rmcilroy, 2014/05/20 12:43:29]

I would just call this "Constants" and rely on the package name (or outer class
if we go that route) to differentiate.

[qsr, 2014/05/20 13:12:45]

 Two mojom can end in the same java package (they can have the same module name)
by design. So I need to use the mojom filename there.

+
+    public static final byte THREE;
+    static {
+        THREE = (byte) 3;
+    }

[rmcilroy, 2014/05/20 12:43:29]

Does this need to be a static block, or could it simply be an assignment?

[qsr, 2014/05/20 13:12:45]

 At the time, it needed to be a static block. I moved from it since, will
update.

[rmcilroy, 2014/05/22 15:52:07]

Still seems to be a static block in the latest patch set.

+
+}