[
https://issues.apache.org/jira/browse/THRIFT-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906125#action_12906125
]
Dave Engberg commented on THRIFT-880:
-------------------------------------
I'll yank the @author tags ... they're left over from the original
pre-incubation files we adapted.
I don't think that JavaME libraries are designed to be built or tested with any
common command-line tools. The standard JavaSE tools wouldn't enforce the
right constraints, and wouldn't have access to the right platform classes for
JavaME/CLDC environments. In particular, the JavaME tools I've used in the
past seem to work off of *.java sources rather than libraries of *.jar files.
As an example of a problem we'd require trying to build and test JavaME using
the standard JDK, if you look at
lib/javame/src/org/apache/thrift/transport/THttpClient.java, you'll see that
the I/O uses:
import javax.microedition.io.Connector;
import javax.microedition.io.HttpConnection;
That uses completely different methods than desktop/server Java networking:
HttpConnection connection = (HttpConnection)Connector.open(url_);
So I think that anyone who consumes this library would be doing so in source
form, and there wouldn't be any good way to build a CLI unit test for this
stuff without pulling in some uncommon compiler+emulator tools:
http://www.j2meforums.com/wiki/index.php/Development_Tools
I did some test code based on our IDL and our HTTP service interface, but that
all went into a really fat Java ME IDE with emulated phone UIs, etc.
If any individual JavaME library files are identical to the "full" Java files,
it would be kind of nice to unify them via a symlink, but the mechanics of this
would be a little ugly, and I'd worry about innocent changes to the normal Java
packages just breaking JavaME. E.g. if you make use of any generics or modern
collections (except Hashtable & Vector) anywhere in the Java library, it won't
compile at all under Java ME.
I think it's safer to think of JavaME as a forked cousin of JavaSE/EE rather
than a subset.
> JavaME code generator and runtime library
> -----------------------------------------
>
> Key: THRIFT-880
> URL: https://issues.apache.org/jira/browse/THRIFT-880
> Project: Thrift
> Issue Type: New Feature
> Components: Compiler (General)
> Affects Versions: 0.4
> Reporter: Dave Engberg
> Fix For: 0.5
>
> Attachments: javame-v1.patch
>
>
> There are a number of mobile devices that use use some variant of the "Java
> Micro Edition" (Java ME) platform for their development environments.
> The JavaME platform is barely a second cousin of modern Java SE/EE, and most
> modern Java libraries like Thrift aren't even conceivable on those devices
> due to lack of things like generics, modern collection classes, etc.
> This basically means that some simple "vanilla" Java code can be used in both
> places, but it's better to consider JavaME as just a separate platform with a
> historic overlap rather than a "subset."
> We've been using a JavaME profile of Thrift (CLDC 1.1) for a while on some of
> our own platforms, and are now making it available to some partners. I've
> cleaned up our code generator and JavaME libraries in this patch for
> (hopeful) inclusion into a Thrift release in the future.
> This includes:
> t_javame_generator.cc based on the 0.4.0 Java generator with heavy
> modifications for the generated code to comply with the ME profile.
> lib/javame - a runtime library for ME devices that is based on a fairly old
> version of the Java libraries (pre-incubation)
> This patch does not modify the main Java generator at all ... this is a
> parallel project and runtime library.
> These changes are too large to reasonably fold into the "Java" generator as
> an option (i.e. that would be a bit like trying to merge the C# and Java
> generators into one.) I realize that results in a bit of a fork.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
