Home > Archive > Open Source Software > November 2007 > C++ implementation of core Java API
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
C++ implementation of core Java API
|
|
| Generic Usenet Account 2007-11-01, 7:18 pm |
| Apologies if someone finds this OT
I am looking for an open-source C++ implementation of Java API ----
something that does not require a Java run-time environment. So far
the only thing that I have found is NewJ from pure-native.com. It
looks good, but it is not open source. Can anyone provide some
pointers?
Zhang
| |
|
| Generic Usenet Account wrote:
> Apologies if someone finds this OT
>
> I am looking for an open-source C++ implementation of Java API ----
> something that does not require a Java run-time environment ...
Zhang;
Sourceforge.net has a number of C++ implementations. Try the site's
"advanced search."
hth,
-Craig
A couple of hits that may interest you ...
<https://sourceforge.net/projects/j2k/>
"A completely portable C++ library, to provide a standard set of classes
similar to Java Common API. It's highly efficient and it follows the
Embedded C++ Standard. It's FREE (LGPL licensed)."
<https://sourceforge.net/projects/stemkit/>
"A set of C++ libraries and build tools that provide core classes to
build a project upon. From exceptions and basic types (String, Integer,
Float, etc.) to collections and tracers. Where possible, Java API is
followed. Implementation is based on STL."
| |
| Mark Space 2007-11-01, 10:14 pm |
| Craig wrote:
> <https://sourceforge.net/projects/j2k/>
> "A completely portable C++ library, to provide a standard set of classes
> similar to Java Common API. It's highly efficient and it follows the
> Embedded C++ Standard. It's FREE (LGPL licensed)."
>
> <https://sourceforge.net/projects/stemkit/>
> "A set of C++ libraries and build tools that provide core classes to
> build a project upon. From exceptions and basic types (String, Integer,
> Float, etc.) to collections and tracers. Where possible, Java API is
> followed. Implementation is based on STL."
Whoa. Cool!
| |
|
| Mark Space wrote:
> Craig wrote:
>
>
> Whoa. Cool!
Lemmee guess: That's a good thing, right?
<grin>
-Craig
| |
| Krazee Brenda 2007-11-02, 4:30 am |
| On Thu, 01 Nov 2007 20:54:15 -0800, Craig wrote:
> Mark Space wrote:
>
> Lemmee guess: That's a good thing, right?
>
> <grin>
> -Craig
Be glad he didn't say "Cool beans".
G talkwarer
| |
| Paul M. Dubuc 2007-11-02, 8:10 am |
| Mark Space wrote:
> Craig wrote:
>
>
> Whoa. Cool!
stemkit looks like an empty project to me.
--
Paul M. Dubuc
| |
|
| Paul M. Dubuc wrote:
> stemkit looks like an empty project to me.
It also has a name suspiciously similar to "rootkit".
--
Lew
| |
| Mark Space 2007-11-02, 7:14 pm |
| Krazee Brenda wrote:
> On Thu, 01 Nov 2007 20:54:15 -0800, Craig wrote:
>
>
> Be glad he didn't say "Cool beans".
Definitely a good thing, since both projects look like abandon-ware, and
are very incomplete. Too bad, even a partial implementation could have
been useful.
But if they had been useful, I would have said " beans." ;-)
| |
|
| Mark Space wrote:
> Krazee Brenda wrote:
>
>
> Definitely a good thing, since both projects look like abandon-ware, and
> are very incomplete. Too bad, even a partial implementation could have
> been useful.
>
> But if they had been useful, I would have said " beans." ;-)
<meh> Sorry 'bout that. You might want to try the "advanced" search on
Sourceforge. The string below sorts (+java +api +"c++") by activity.
Looks more promising than the last.
hth,
-Craig
<http://sourceforge.net/search/index...e=0&form_cat=18>
| |
| Roland Pibinger 2007-11-02, 7:14 pm |
| On Fri, 02 Nov 2007 19:18:01 GMT, Mark Space wrote:
>Definitely a good thing, since both projects look like abandon-ware, and
>are very incomplete. Too bad, even a partial implementation could have
>been useful. But if they had been useful, I would have said " beans." ;-)
It's not so simple to 'port' the core Java API to C++ as it seams at
first sight. Java e.g. uses references to objects. The 'copy' of a
container doesn't copy objects, only references. In C++ you probably
would disable copying of the container but then your container differs
from a Java container. Moreover, the developement of a production
quality library of that size is quite difficult and time-consuming.
More (mostly abandoned) Java-like libraries:
http://acdk.sourceforge.net/acdk/docs/hb/acdk_hb.html
http://bluelib.sourceforge.net/
http://www.jakelib.org/lib/jakelib2/index.html
http://www.pure-native.com/newj/faq.html
http://www.decompile.com/not_invent...valib/index.htm
http://www.mike95.com/c%5Fplusplus/
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
| |
| Krazee Brenda 2007-11-03, 4:25 am |
| On Fri, 02 Nov 2007 22:00:00 GMT, Roland Pibinger wrote:
> It's not so simple to 'port' the core Java API to C++ as it seams at
> first sight. Java e.g. uses references to objects. The 'copy' of a
> container doesn't copy objects, only references. In C++ you probably
> would disable copying of the container but then your container differs
> from a Java container. Moreover, the developement of a production
> quality library of that size is quite difficult and time-consuming.
McCoyHatfieldware
| |
| James Kanze 2007-11-03, 8:11 am |
| On Nov 2, 11:00 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
> On Fri, 02 Nov 2007 19:18:01 GMT, Mark Space wrote:
[color=darkred]
> It's not so simple to 'port' the core Java API to C++ as it
> seams at first sight.
It depends on what you mean by "port". Just mimicing the
Java API exactly, mapping what Java calls references to C++
pointers, is really a problem, but it is stupid, even if you're
using garbage collection. The languages are different, and are
(or should be) used differently.
> Java e.g. uses references to objects. The 'copy' of a
> container doesn't copy objects, only references.
Do Java containers support copy? Java doesn't have copy
constructors. Java doesn't need or want copy constructors,
because Java uses reference semantics, not value semantics.
You can do this in C++ too, but it's stupid. It doesn't really
fit into the language. (And again, this is true even if you use
garbage collection.) What you want to do is to "adapt" the Java
API to C++, taking what's good in it, and adapting it to the C++
idiom. (For example, considered globally, Swing isn't bad at
all---it seems significantly better than the C++ GUI libraries
I've looked at. And adapting Swing to the C++ idiom could even
fix some of the minor flaws it has, e.g. by returning Dimension
as a value, rather than as a reference.)
For other things, you might not want to adopt Java directly.
The Java collections may be better than the C++ containers
(which a probably about the worst I've seen, from a design point
of view), but they still are far from known best practice.
There are libraries available (e.g. OSE) which are better than
both.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
| |
| Roland Pibinger 2007-11-03, 8:11 am |
| On Sat, 03 Nov 2007 10:07:00 -0000, James Kanze wrote:
>
>It depends on what you mean by "port". Just mimicing the
>Java API exactly, mapping what Java calls references to C++
>pointers, is really a problem, but it is stupid, even if you're
>using garbage collection. The languages are different, and are
>(or should be) used differently.
IMO, it's possible to 'transfer' the core Java API to C++ if you
explicitly address the differences between the two languages in your
design. Besides better usability the advantage would be that nowadays
more people know the Java API compared to those who know the C++ std
library (even among C++ programmers ;-)
>
>Do Java containers support copy? Java doesn't have copy
>constructors. Java doesn't need or want copy constructors,
Right, nobody needs them in Java (although Java has copy constructors
and the clone function) and nobody needs them in C++. In Java, C++ and
other languages objects in the OOP sense are non-copyable, at least
conceptually. But in C++ you cannot e.g. just return a shallow copy of
a container of pointers from a function as you would do in Java.
>because Java uses reference semantics, not value semantics.
>You can do this in C++ too, but it's stupid. It doesn't really
>fit into the language. (And again, this is true even if you use
>garbage collection.) What you want to do is to "adapt" the Java
>API to C++, taking what's good in it, and adapting it to the C++
>idiom.
That's the point. Adapt the Java API to C++ idioms. You can do the
same in C++ with pointers what you can do with references in Java. As
long as you don't try to copy the container the differences are minor.
Of course, in C++ you always have to take ownership into
consideration.
>(For example, considered globally, Swing isn't bad at
>all---it seems significantly better than the C++ GUI libraries
>I've looked at. And adapting Swing to the C++ idiom could even
>fix some of the minor flaws it has, e.g. by returning Dimension
>as a value, rather than as a reference.)
I wouldn't consider Swing a 'core' Java API (and many GUI experts
wouldn't agree with your assessment of Swing).
>For other things, you might not want to adopt Java directly.
>The Java collections may be better than the C++ containers
>(which a probably about the worst I've seen, from a design point
>of view),
STL was meant as a proof of concept. It would have needed some
iterations in the real world to become more user-friendly. The current
'value only' approach in STL is unnecessary limiting but its
functional programming concepts are more fashionable today than they
were in 1995.
>but they still are far from known best practice.
>There are libraries available (e.g. OSE) which are better than
>both.
Maybe, but familiarity is the 'selling proposition' for the Java API.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch
| |
|
| Krazee Brenda wrote:
> McCoyHatfieldware
???
--
Lew
| |
|
| James Kanze wrote:
Roland Pibinger wrote:[color=darkred]
> That's the point. Adapt the Java API to C++ idioms. You can do the
> same in C++ with pointers what you can do with references in Java. As
> long as you don't try to copy the container the differences are minor.
> Of course, in C++ you always have to take ownership into
> consideration.
Some years back I worked on a multi-threaded C++ app. I wrote C++ versions of
Java's Thread and Runnable classes for it, based on a freely-available
pthreads library.
It turned out that it was tricky to get the semantics to match, in part
because a C++ reference (type&) is not the same as a Java reference. Also
tricky was to get Thread to be startable on its own or with a Runnable argument.
It turned out to be very useful to have a C++ equivalent to these classes. It
sure was simpler to use them than the raw pthreads lib.
There can be a distinct value to having Java-like libraries in C++. More
power to those who develop such libs; it ain't easy.
--
Lew
| |
| Krazee Brenda 2007-11-03, 10:21 pm |
| On Sat, 03 Nov 2007 10:21:04 -0400, Lew wrote:
> Some years back I worked on a multi-threaded C++ app. I wrote C++
versions of
> Java's Thread and Runnable classes for it, based on a freely-available
> pthreads library.
>
> It turned out that it was tricky to get the semantics to match, in part
> because a C++ reference (type&) is not the same as a Java reference.
Also
> tricky was to get Thread to be startable on its own or with a Runnable
argument.
McCoyHatfieldware
| |
|
| Krazee Brenda wrote:
> McCoyHatfieldware
What are you on about?
--
Lew
| |
| Krazee Brenda 2007-11-04, 4:37 am |
| On Sat, 03 Nov 2007 22:30:20 -0400, Lew wrote:
> Krazee Brenda wrote:
>
> What are you on about?
>
> --
> Lew
Ganjaware
| |
|
| Krazee Brenda wrote:
> On Sat, 03 Nov 2007 22:30:20 -0400, Lew wrote:
>
>
> Ganjaware
Plonk.
--
Lew
| |
| Peter Seiler 2007-11-04, 10:15 pm |
| Krazee Brenda - 04.11.2007 08:19 :
> On Sat, 03 Nov 2007 22:30:20 -0400, Lew wrote:
>
>
> Ganjaware
KB, your endless "...ware"-contributions are very
readworthy, impressive and remarkable. So your monthly upper
statistic-ranking of your (re)postings is not wondering.
BTW: And please do not quote the right delimited (-- ) sig again. THX.
--
by(e) PS
spam will be killfiled
| |
| James Kanze 2007-11-04, 10:15 pm |
| On Nov 3, 3:21 pm, Lew <l...@lewscanon.com> wrote:
> James Kanze wrote:
> Roland Pibinger wrote:
[color=darkred]
> Some years back I worked on a multi-threaded C++ app. I wrote
> C++ versions of Java's Thread and Runnable classes for it,
> based on a freely-available pthreads library.
> It turned out that it was tricky to get the semantics to
> match, in part because a C++ reference (type&) is not the same
> as a Java reference.
That's because Java's references are really what C++ calls
pointers. Most earlier C++ threading libraries had pretty much
the same interface as the Java one.
> Also tricky was to get Thread to be startable on its own or
> with a Runnable argument.
What was the problem? It always seems pretty trivial to me.
The big problem in C++ without garbage collection is managing
the lifetime of the thread object of a detached thread. Mainly
because the lifetime is largely irrelevant except for memory
management issues. But there are solutions which work there as
well, and for the most part, if you want to support clean
shutdown, you'll need to use them anyway.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
| |
| hawkingliu@gmail.com 2007-11-05, 8:12 am |
| That's what I am finding now!
Thank you very much, and I think it will be very useful.
On Nov 2, 3:53 am, Craig <netburg...@REMOVEgmail.com> wrote:
> Generic Usenet Account wrote:
>
>
> Zhang;
>
> Sourceforge.net has a number of C++ implementations. Try the site's
> "advanced search."
>
> hth,
> -Craig
>
> A couple of hits that may interest you ...
>
> <https://sourceforge.net/projects/j2k/>
> "A completely portable C++ library, to provide a standard set of classes
> similar to Java Common API. It's highly efficient and it follows the
> Embedded C++ Standard. It's FREE (LGPL licensed)."
>
> <https://sourceforge.net/projects/stemkit/>
> "A set of C++ libraries and build tools that provide core classes to
> build a project upon. From exceptions and basic types (String, Integer,
> Float, etc.) to collections and tracers. Where possible, Java API is
> followed. Implementation is based on STL."
| |
| Roedy Green 2007-11-05, 7:24 pm |
| On Fri, 02 Nov 2007 19:18:01 GMT, Mark Space
<markspace@sbc.global.net> wrote, quoted or indirectly quoted someone
who said :
>
>Definitely a good thing, since both projects look like abandon-ware, and
>are very incomplete. Too bad, even a partial implementation could have
>been useful.
The older you get the more wary you are of relying on any tool that
does not have multiple sources.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
| |
| apm35@student.open.ac.uk 2007-11-06, 7:19 pm |
| On 1 Nov, 19:53, Craig <netburg...@REMOVEgmail.com> wrote:
[color=darkred]
> Sourceforge.net has a number of C++ implementations. Try the site's
> "advanced search."
>
> hth,
> -Craig
> <https://sourceforge.net/projects/stemkit/>
> "A set of C++ libraries and build tools that provide core classes to
> build a project upon. From exceptions and basic types (String, Integer,
> Float, etc.) to collections and tracers. Where possible, Java API is
> followed. Implementation is based on STL."
This one is pre-alpha. There is no web site and no released files. :-(
-Andrew Marlow
| |
|
| apm35@student.open.ac.uk wrote:
> On 1 Nov, 19:53, Craig <netburg...@REMOVEgmail.com> wrote:
>
>
>
> This one is pre-alpha. There is no web site and no released files. :-(
>
> -Andrew Marlow
>
Yea;
Sorry Andrew. Looks like a wash. If you find anything let us know though.
thx,
-Craig
|
|
|
|
|