Generate java bindings for constants.

mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl

Index: mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl
diff --git a/mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl b/mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl
new file mode 100644
index 0000000000000000000000000000000000000000..1914aa246851feacfc71ca6519687c6be412d768
--- /dev/null
+++ b/mojo/public/tools/bindings/generators/java_templates/constant_definition.tmpl
@@ -0,0 +1,5 @@
+{% from "java_macros.tmpl" import build_default %}
+
+{% macro constant_def(constant) %}
+public static final {{constant.kind|java_type}} {{constant|constant_name}} = {{build_default(module, constant.kind, constant.value)|indent(4)}};

[rmcilroy, 2014/05/25 22:55:10]

Do we need build_default()?  The cpp binding generator gets away
withexpression_to_text(), I'm pretty sure we could too assuming a mojom const
can't be anything other than a number or string literal? If not, could you add
an examples to the the sample mojom files which use the other const types.

[qsr, 2014/05/26 08:41:20]

 Updated  build_default() to be a lot simpler, but I let it there, because this
will also be used for default field value, and I'd like to let this at a single
place if we ever update the idl to allow default array and struct as it was a
few days ago.

[rmcilroy, 2014/05/26 11:13:48]

I am fine with build_default existing (and being used for fields), but would
prefer you use expression_to_text() here currently otherwise we are supporting a
different IDL from the CPP generator. It would be easy to swap the filter used
here if the IDL added back support for const arrays/structs.

[qsr, 2014/05/26 12:33:43]

 I don't understand. The macro is only using expression_to_text().

[rmcilroy, 2014/05/27 09:44:34]

I was presuming you were going to update the build_default macro in a later CL
to support arrays and objects again when it was used to build default field
values - is this not the case? If not, then this is fine, though maybe renaming
the macro to build_constant() would be clearer?

+{% endmacro %}