Recommend trying to make that work with the docker build image, then we can easily add a CI job for it.
- Jim On Sun, Dec 30, 2018 at 4:27 PM Allen George <allen.geo...@gmail.com> wrote: > AFAICT, libthrift can be used in Android, but…I’ll actually have to use an > IDL, generate code and try create an app to confirm this. It’ll take some > time because I know nothing about Android. > > Allen > > > On December 30, 2018 at 11:15:02, Allen George (allen.geo...@gmail.com) > wrote: > My gut feeling is that almost no one will be using a Java ME target > anymore. These days people who use Java will be doing so as part of an > Android project. As a result, it’s probably better for us to try use the > main Java library in Android, see what breaks, and change that library - if > possible - to cover both targets. Since Java (compiler + library) is > responsible for a significant chunk of the project’s JIRAs, focus on a > single Java target would have the added advantage of cleaning up the bug > tracker. > > Allen > > > ------------------------------ > *From:* James E. King III <jk...@apache.org> > *Sent:* Sunday, December 30, 2018 9:58 AM > *To:* dev@thrift.apache.org > *Subject:* The JavaME library is rotting - do we need it? > > Before calling a vote on this, the last checkins to lib/javame were in > 2015, and when you compare the sources to what's in lib/java, the > differences are that the lib/java library has received updates, but the > lib/javame library has not. For example a configurable maximum frame size. > > Do we really need two? In C++ one would just use macros to provide the > kind of support that seems to be the difference between the two - for > example using String instead of StringBuffer or URL. Perhaps JavaME has > these things now however? > > Thoughts? Do we need a separate implementation for JavaME? > > - Jim >
