You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "James E. King III" <jk...@apache.org> on 2018/12/30 14:57:54 UTC
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
Re: The JavaME library is rotting - do we need it?
Posted by "James E. King III" <jk...@apache.org>.
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 <al...@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.george@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
>
Re: The JavaME library is rotting - do we need it?
Posted by Allen George <al...@gmail.com>.
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.george@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
Re: The JavaME library is rotting - do we need it?
Posted by Allen George <al...@gmail.com>.
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