C++ implementation of core Java API

[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. 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]

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]

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!

[Craig]

Mark Space wrote:

Craig wrote:

><https://sourceforge.net/projects/j2k/>

<https://sourceforge.net/projects/stemkit/>

Whoa. Cool!

Lemmee guess: That's a good thing, right?

<grin>
-Craig

[Krazee Brenda]

On Thu, 01 Nov 2007 20:54:15 -0800, Craig wrote:

Mark Space wrote:

Craig wrote:

<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

[Paul M. Dubuc]

Mark Space wrote:

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!

stemkit looks like an empty project to me.

--
Paul M. Dubuc

[Lew]

Paul M. Dubuc wrote:

stemkit looks like an empty project to me.

It also has a name suspiciously similar to "rootkit".

--
Lew

[Mark Space]

Krazee Brenda wrote:

On Thu, 01 Nov 2007 20:54:15 -0800, Craig wrote:

>Mark Space wrote:

>>Craig wrote:

<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]

Mark Space wrote:

Krazee Brenda wrote:

>On Thu, 01 Nov 2007 20:54:15 -0800, Craig wrote:

>>Mark Space wrote:
Craig wrote:

<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]

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 "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_invente...alib/index.htm
http://www.mike95.com/c%5Fplusplus/
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Krazee Brenda]

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]

On Nov 2, 11:00 pm, [e-mail] (Roland Pibinger) wrote:

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 "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.

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Roland Pibinger]

On Sat, 03 Nov 2007 10:07:00 -0000, James Kanze wrote:

>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 ;-)

>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.

>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

[Lew]

Krazee Brenda wrote:

McCoyHatfieldware

???

--
Lew

[Lew]

James Kanze wrote:

>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.

Roland Pibinger wrote:

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]

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

[Lew]

Krazee Brenda wrote:

McCoyHatfieldware

What are you on about?

--
Lew

[Krazee Brenda]

On Sat, 03 Nov 2007 22:30:20 -0400, Lew wrote:

Krazee Brenda wrote:

McCoyHatfieldware

What are you on about?

--
Lew

Ganjaware

[Lew]

Krazee Brenda wrote:

On Sat, 03 Nov 2007 22:30:20 -0400, Lew wrote:

>Krazee Brenda wrote:

>>McCoyHatfieldware

What are you on about?

--
Lew

Ganjaware

Plonk.

--
Lew

[Roland Pibinger]

On Sat, 03 Nov 2007 10:21:04 -0400, Lew <le*@lewscanon.comwrote:

>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.

A Java reference is largely the same as a C/C++ pointer whereas C++
references are 'real' references.

>There can be a distinct value to having Java-like libraries in C++.

I agree with that. There isn't much activity in this regard any more,
though (and in C++ in general), see e.g.
http://doc.trolltech.com/qq/qq12-qt4-iterators.html
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Lew]

Roland Pibinger wrote:

A Java reference is largely the same as a C/C++ pointer whereas C++
references are 'real' references.

Nice pat description, but not accurate in detail. There are significant
differences in the semantics of Java references compared to C++ pointers or to
C++ references. That's the lesson I took away from implementing Java's Thread
and Runnable semantics in C++, and from other experience. In fact, thinking
of Java references as "the same", largely or otherwise, as either of the
others will lead to trouble in the code.

--
Lew

[Peter Seiler]

Krazee Brenda - 04.11.2007 08:19 :

On Sat, 03 Nov 2007 22:30:20 -0400, Lew wrote:

>Krazee Brenda wrote:

>>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]

On Nov 4, 2:57 pm, Lew <[e-mail]:

Roland Pibinger wrote:

A Java reference is largely the same as a C/C++ pointer
whereas C++ references are 'real' references.

Nice pat description, but not accurate in detail. There are
significant differences in the semantics of Java references
compared to C++ pointers or to C++ references.

Such as? C++ pointers do have additional features: they are
first class objects, for example and they support pointer
arithmetic. But since we're talking about emulating Java in
C++, and not the reverse, you can just ignore the added
features.

That's the lesson I took away from implementing Java's Thread
and Runnable semantics in C++, and from other experience. In
fact, thinking of Java references as "the same", largely or
otherwise, as either of the others will lead to trouble in the
code.

Trying to treat pointers as first class objects in Java will
lead to problems in Java, yes. If you're considering mapping in
the two directions, then you do have very distinctive concepts.
But if you're looking for the functionality of Java references
in C++, pointers have everything that is needed. (Of course,
you'll probably want to install garbage collection. But you'll
probably want to do that anyway.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Nov 3, 3:21 pm, Lew <[e-mail]:

James Kanze wrote:

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.

Roland Pibinger wrote:

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.

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[hawkingliu]

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 <[e-mail]:

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."

[Roedy Green]

On Fri, 02 Nov 2007 19:18:01 GMT, Mark Space
<ma*******@sbc.global.netwrote, 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]

On 1 Nov, 19:53, Craig <[e-mail]:

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]

ap***@student.open.ac.uk wrote:

On 1 Nov, 19:53, Craig <[e-mail]:

>>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