Discussion:
C++ implementation of core Java API
(too old to reply)
Generic Usenet Account
2007-11-01 19:38:35 UTC
Permalink
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
Craig
2007-11-01 19:53:52 UTC
Permalink
Post by Generic Usenet Account
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-02 02:47:53 UTC
Permalink
Post by Craig
<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!
Craig
2007-11-02 04:54:15 UTC
Permalink
Post by Mark Space
Post by Craig
<https://sourceforge.net/projects/j2k/>
<https://sourceforge.net/projects/stemkit/>
Whoa. Cool!
Lemmee guess: That's a good thing, right?

<grin>
-Craig
Krazee Brenda
2007-11-02 07:49:11 UTC
Permalink
Post by Craig
Post by Mark Space
Post by Craig
<https://sourceforge.net/projects/j2k/>
<https://sourceforge.net/projects/stemkit/>
Whoa. Cool!
Lemmee guess: That's a good thing, right?
<grin>
-Craig
Be glad he didn't say "Cool beans".

Geektalkwarer
Mark Space
2007-11-02 19:18:01 UTC
Permalink
Post by Krazee Brenda
Post by Craig
Post by Mark Space
Post by Craig
<https://sourceforge.net/projects/j2k/>
<https://sourceforge.net/projects/stemkit/>
Whoa. Cool!
Lemmee guess: That's a good thing, right?
<grin>
-Craig
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 "cool beans." ;-)
Craig
2007-11-02 19:58:53 UTC
Permalink
Post by Mark Space
Post by Krazee Brenda
Post by Craig
Post by Mark Space
Post by Craig
<https://sourceforge.net/projects/j2k/>
<https://sourceforge.net/projects/stemkit/>
Whoa. Cool!
Lemmee guess: That's a good thing, right?
<grin>
-Craig
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 "cool 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.php?words=%28%2Bjava+%2Bapi+%2B%22c%2B%2B%22%29&sort=percentile&sortdir=desc&offset=0&type_of_search=soft&pmode=0&form_cat=18>
Roland Pibinger
2007-11-02 22:00:00 UTC
Permalink
Post by Mark Space
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 "cool 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_invented_here/Javalib/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 09:07:43 UTC
Permalink
Post by Roland Pibinger
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
Lew
2007-11-03 14:07:28 UTC
Permalink
Post by Krazee Brenda
McCoyHatfieldware
???
--
Lew
James Kanze
2007-11-03 10:07:00 UTC
Permalink
Post by Roland Pibinger
Post by Mark Space
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 "cool beans." ;-)
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.
Post by Roland Pibinger
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:***@gmail.com
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
Roland Pibinger
2007-11-03 11:36:41 UTC
Permalink
Post by James Kanze
Post by Roland Pibinger
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.
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 ;-)
Post by James Kanze
Post by Roland Pibinger
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,
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.
Post by James Kanze
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.
Post by James Kanze
(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).
Post by James Kanze
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.
Post by James Kanze
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
Lew
2007-11-03 14:21:04 UTC
Permalink
Post by Roland Pibinger
Post by James Kanze
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.
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-04 01:47:19 UTC
Permalink
Post by Lew
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
Post by Lew
tricky was to get Thread to be startable on its own or with a Runnable argument.
McCoyHatfieldware
Lew
2007-11-04 02:30:20 UTC
Permalink
Post by Krazee Brenda
McCoyHatfieldware
What are you on about?
--
Lew
Krazee Brenda
2007-11-04 07:19:43 UTC
Permalink
Post by Lew
Post by Krazee Brenda
McCoyHatfieldware
What are you on about?
--
Lew
Ganjaware
Lew
2007-11-04 10:03:59 UTC
Permalink
Post by Krazee Brenda
Post by Lew
Post by Krazee Brenda
McCoyHatfieldware
What are you on about?
--
Lew
Ganjaware
Plonk.
--
Lew
Peter Seiler
2007-11-04 10:29:33 UTC
Permalink
Post by Krazee Brenda
Post by Lew
Post by Krazee Brenda
McCoyHatfieldware
What are you on about?
--
Lew
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 21:07:42 UTC
Permalink
Post by Roland Pibinger
Post by James Kanze
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.
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:***@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Roedy Green
2007-11-05 21:50:10 UTC
Permalink
On Fri, 02 Nov 2007 19:18:01 GMT, Mark Space
Post by Mark Space
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
Paul M. Dubuc
2007-11-02 12:32:14 UTC
Permalink
Post by Mark Space
Post by Craig
<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!
stemkit looks like an empty project to me.
--
Paul M. Dubuc
Lew
2007-11-02 13:34:59 UTC
Permalink
Post by Paul M. Dubuc
stemkit looks like an empty project to me.
It also has a name suspiciously similar to "rootkit".
--
Lew
h***@gmail.com
2007-11-05 10:44:29 UTC
Permalink
That's what I am finding now!
Thank you very much, and I think it will be very useful.
Post by Craig
Post by Generic Usenet Account
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."
a***@student.open.ac.uk
2007-11-06 12:59:07 UTC
Permalink
Post by Craig
Post by Generic Usenet Account
I am looking for an open-source C++ implementation of Java API ----
something that does not require a Java run-time environment ...
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
Craig
2007-11-06 16:51:42 UTC
Permalink
Post by a***@student.open.ac.uk
Post by Craig
Post by Generic Usenet Account
I am looking for an open-source C++ implementation of Java API ----
something that does not require a Java run-time environment ...
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
Yea;

Sorry Andrew. Looks like a wash. If you find anything let us know though.

thx,
-Craig

Loading...