[
https://issues.apache.org/jira/browse/THRIFT-6190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-6190:
-------------------------------
Description:
Nothing in the tree builds or tests the JavaME binding, and unlike the other
bindings without a CI job, lib/javame has no build integration at all to hook
one onto.
* There is no lib/javame/Makefile.am and no configure.ac entry for it. The
directory appears only in lib/Makefile.am, in EXTRA_DIST (line 115) and in a
dist rule that removes gen-javame (line 108).
* There is no entry in test/tests.json, so it is not part of the cross-test
matrix either.
* There is no CI job, and no configure flag to turn one on.
The binding is nevertheless shipped in the release tarball. It has therefore
never been compiled by any build in this repository. THRIFT-6036 and
THRIFT-6055 both had to be compiled and run by hand to verify them.
h3. Verified possible before filing
In the thrift:jammy image with openjdk 17.0.19, using the recipe already
documented in the header of lib/javame/test/TestRecursionDepth.java:
{code}
thrift --gen javame -o . test/RecursionDepth.thrift
javac -d /tmp/jme -cp . \
$(find src -name '*.java' ! -name 'THttpClient.java') \
gen-javame/*.java test/TestRecursionDepth.java
java -cp /tmp/jme TestRecursionDepth
{code}
The compile succeeds with only deprecation and unchecked notes, and the test
reports "18 checks, 0 failure(s)". So a check is a matter of writing it, not of
provisioning anything: the JDK is already in the images.
h3. One permanent limitation, better stated up front than discovered later
THttpClient.java imports javax.microedition.io.Connector and
javax.microedition.io.HttpConnection, which no JDK provides. Supplying a
CLDC/MIDP jar is not an option for an ASF build: Oracle's is proprietary and
microemu is LGPL. A check can therefore cover 39 of the 40 source files and
must exclude THttpClient.java, exactly as the existing test recipe does.
h3. Scope
This is a compile-and-smoke check, not parity with the other bindings' CI jobs.
lib/javame has no server transport and no acceptor, and there is no tests.json
entry, so cross tests are out of scope. What such a job would buy is that the
binding still compiles and that its one existing test still passes -- which is
precisely what had to be established by hand for the last two changes to it.
Noticed while writing this up, and separable: LANGUAGES.md links to
lib/javame/README.md, which does not exist.
Compare THRIFT-6002 (netstd), THRIFT-6003 (haxe), THRIFT-6170 (D), THRIFT-6171
(Erlang) and THRIFT-6172 (Dart), which are the same gap in bindings that at
least have a build harness.
_Drafted with AI assistance (Claude Opus 5); reviewed and filed by Jens Geyer._
was:
Nothing in the tree builds or tests the JavaME binding, and unlike the other
bindings without a CI job, lib/javame has no build integration at all to hook
one onto.
* There is no lib/javame/Makefile.am and no configure.ac entry for it. The
directory appears only in lib/Makefile.am, in EXTRA_DIST (line 115) and in a
dist rule that removes gen-javame (line 108).
* There is no entry in test/tests.json, so it is not part of the cross-test
matrix either.
* There is no CI job, and no configure flag to turn one on.
The binding is nevertheless shipped in the release tarball. It has therefore
never been compiled by any build in this repository. THRIFT-6036 and
THRIFT-6055 both had to be compiled and run by hand to verify them.
h3. Verified possible before filing
In the thrift:jammy image with openjdk 17.0.19, using the recipe already
documented in the header of lib/javame/test/TestRecursionDepth.java:
{code}
thrift --gen javame -o . test/RecursionDepth.thrift
javac -d /tmp/jme -cp . \
$(find src -name '*.java' ! -name 'THttpClient.java') \
gen-javame/*.java test/TestRecursionDepth.java
java -cp /tmp/jme TestRecursionDepth
{code}
The compile succeeds with only deprecation and unchecked notes, and the test
reports "18 checks, 0 failure(s)". So a check is a matter of writing it, not of
provisioning anything: the JDK is already in the images.
h3. One permanent limitation, better stated up front than discovered later
THttpClient.java imports javax.microedition.io.Connector and
javax.microedition.io.HttpConnection, which no JDK provides. Supplying a
CLDC/MIDP jar is not an option for an ASF build: Oracle's is proprietary and
microemu is LGPL. A check can therefore cover 39 of the 40 source files and
must exclude THttpClient.java, exactly as the existing test recipe does.
h3. Scope
This is a compile-and-smoke check, not parity with the other bindings' CI jobs.
lib/javame has no server transport and no acceptor, and there is no tests.json
entry, so cross tests are out of scope. What such a job would buy is that the
binding still compiles and that its one existing test still passes -- which is
precisely what had to be established by hand for the last two changes to it.
Noticed while writing this up, and separable: LANGUAGES.md links to
lib/javame/README.md, which does not exist.
Compare THRIFT-6002 (netstd), THRIFT-6003 (haxe), THRIFT-6170 (D), THRIFT-6171
(Erlang) and THRIFT-6172 (Dart), which are the same gap in bindings that at
least have a build harness.
> Add a compile and test check for the JavaME library
> ---------------------------------------------------
>
> Key: THRIFT-6190
> URL: https://issues.apache.org/jira/browse/THRIFT-6190
> Project: Thrift
> Issue Type: New Feature
> Components: Build Process, JavaME - Library
> Reporter: Jens Geyer
> Priority: Major
>
> Nothing in the tree builds or tests the JavaME binding, and unlike the other
> bindings without a CI job, lib/javame has no build integration at all to hook
> one onto.
> * There is no lib/javame/Makefile.am and no configure.ac entry for it. The
> directory appears only in lib/Makefile.am, in EXTRA_DIST (line 115) and in a
> dist rule that removes gen-javame (line 108).
> * There is no entry in test/tests.json, so it is not part of the cross-test
> matrix either.
> * There is no CI job, and no configure flag to turn one on.
> The binding is nevertheless shipped in the release tarball. It has therefore
> never been compiled by any build in this repository. THRIFT-6036 and
> THRIFT-6055 both had to be compiled and run by hand to verify them.
> h3. Verified possible before filing
> In the thrift:jammy image with openjdk 17.0.19, using the recipe already
> documented in the header of lib/javame/test/TestRecursionDepth.java:
> {code}
> thrift --gen javame -o . test/RecursionDepth.thrift
> javac -d /tmp/jme -cp . \
> $(find src -name '*.java' ! -name 'THttpClient.java') \
> gen-javame/*.java test/TestRecursionDepth.java
> java -cp /tmp/jme TestRecursionDepth
> {code}
> The compile succeeds with only deprecation and unchecked notes, and the test
> reports "18 checks, 0 failure(s)". So a check is a matter of writing it, not
> of provisioning anything: the JDK is already in the images.
> h3. One permanent limitation, better stated up front than discovered later
> THttpClient.java imports javax.microedition.io.Connector and
> javax.microedition.io.HttpConnection, which no JDK provides. Supplying a
> CLDC/MIDP jar is not an option for an ASF build: Oracle's is proprietary and
> microemu is LGPL. A check can therefore cover 39 of the 40 source files and
> must exclude THttpClient.java, exactly as the existing test recipe does.
> h3. Scope
> This is a compile-and-smoke check, not parity with the other bindings' CI
> jobs. lib/javame has no server transport and no acceptor, and there is no
> tests.json entry, so cross tests are out of scope. What such a job would buy
> is that the binding still compiles and that its one existing test still
> passes -- which is precisely what had to be established by hand for the last
> two changes to it.
> Noticed while writing this up, and separable: LANGUAGES.md links to
> lib/javame/README.md, which does not exist.
> Compare THRIFT-6002 (netstd), THRIFT-6003 (haxe), THRIFT-6170 (D),
> THRIFT-6171 (Erlang) and THRIFT-6172 (Dart), which are the same gap in
> bindings that at least have a build harness.
> _Drafted with AI assistance (Claude Opus 5); reviewed and filed by Jens
> Geyer._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
