Function pointers (Callback functions) in Java ?

O

Oscar kind

exquisitus said:
I have a heirarchical ADT whose innermost structure is a set of records.
Each record (C struct) has several fields and represents data
received from a real time feed. In C++, I am using the BOOST library to
allocate a memory pool from which I can request memory slices as and
when I need it. I can write the data directly from my feed to memory,
with (almost) no latency.

If the feed delivers the data exactly as stored, this is indeed ideal.
Java however, does not support structures like C does.

If there are slight differences however, you may want to evaluate a solution
like this:
- The feed handler receives a message, and determines it's type (if there
is more than one).
- Bases on the type, it creates a record, and gives the message to the
contructor.
- This constuctor then fills the "structure"

This is a data centric solution (and not nescessarily the best), and thus
favors objects. This as opposed to a process centric solution, that by its
nature favors stuctures. You'll realise that each is more appropriate in
different cases.

In Java (I am a newbie - so hopefully you can
correct me), I find that I have to wrap up the ADT which is so naturally
a struct, into a heavy, clumsy object. Everytime I receive data, I have
to create a new data object (an encapsulation of the C struct) and then
add it to my array.

Not entirely: the struct becomes the object. The easiest way to do that is
to add the method that fills if to the structure, and you have an object.
The mconstructure I mentioned above is an example of that.

The perfomance hit on creating so many objects is
(unsuprisingly) abysmal when compared to the C++ code. In practise, I
can expect to receive about 50 such records per second, and can receive
as much as 50,000 records in total. The thought of spawning 50 new
object a second - not to mention having 50,000 bloated objects hanging
around in memory is not a pleasing prospect.

Objects don't have to be that bloated: the performance hit in terms of
storage only becomes big if the amount of fields in the structure is
small (maybe 5 or less, but I have no real knowledge of that).

So I will say once again (and this is not to encite the wrath of the
more experienced Java programmers). Please tell me it isn't so (I will
gladly accept a better solution if there is one - I have no ego as far
as this is concerned). There must be another way - a better way of
dumping these records into memory without having to create a new object
every time the data is received.

Alas, there is o other way: Java only knows of one type of structure, and
that is an Object (or subclasses).

Also, Java has no pointers, in the sense that it allows neither pointer
arithmetic, nor referencing functions (or methods, as Java insists on
calling them). So for a callback, you cannot use anything other than
objects.

Note that this isn't as bad as it may seem: you only create one object per
callback. This is regardless of how many times the callback is used: the
callback method is called on the same object again and again.
 
C

Chris Uppal

exquisitus said:
</snip>

WHY is everyone jumping to the conclusion that I am adverse to objects?.
Well,

I have to wrap up the ADT which is so naturally
a struct, into a heavy, clumsy object.
and:

The thought of spawning 50 new object a second - not to mention
having 50,000 bloated objects hanging around in memory is not a
pleasing prospect.

seem to justify such a conclusion quite comprehensively.

I simply dont like the idea of spawning a new object (with all the
concomitant baggage) when a simple struct will do.

But /what/ baggage ?

Any anyway, Java has ints, floats, booleans (and a few variations thereon) and
objects. That's all. If you don't want to use objects then don't use Java.
It really is that simple.

If you /do/ want to use objects, then maybe you'll like Java. Some people do,
some don't.

If you want to use objects, but /only sometimes/, then you'll have to stick
with a hybrid language like C++.

I'm trying to learn Java by jumping in at the deep end

Please don't take this as an insult, but it doesn't seem to be working. The
trouble seems to be that, not having a background in Java fundamentals, you
naturally are trying to work by thinking in C++ and translating into Java as
best you can. That's a poor way to learn a new language (C++ and Java are much
less similar, even in spirit, than they look), and a poor way to program. Your
instincts and intuitions will be misleading you at every step, even if you /do/
manage to find what seems to be an equivalent to some C++ feature. That's
especially true if you have typically not made much use of the OO support in
C++ (which would not be unusual), in which case you won't even be on the right
wavelength to start making effective use of Java.

But likewise,
you guys have to losen upa nd stop thinking that everyone is critisizing
your 'beloved' Java. Like I said, its only a language ...

Hmm. I think /you/ are jumping to conclusions here. I am certainly not a
great admirer of Java (OK, it's a decent enough language -- if you don't look
too hard -- and can be quite pleasant to program in, but it's very second rate
compared to some of the competition.) Indeed, I become less of an admirer with
each bit of imitation-C++ crud that gets grafted on.

-- chris
 
A

Andrew McDonagh

see comment below (and note I made the mistake of assigning the new
object to a local var called 'callback'. I meant to assign it to the
member var called 'callback'

so code above should have been:
I am new the Java, and I am trying to get a handle on the above
callback example. I wrote a parsing engine that used call back
functions, and I used reflection (a sackable offense as I am now aware
of it).
;-)


In the above I don't see the Opps interface. I guess i am not not
making the connection

The code was a very simple example of creating a named inner class
implementation of an interface, rather than simply creating an anonymous
inner class.

The MyCallbackUsingClass constructor is creating an instance of
OopsImplementation and assigning it to its member variable 'callback'

The Type of the member var 'callback' is Oops

The actual interface code was in the post I replied too - I simply
didn't repeat it. Sorry if this caused any confusion.

Its may be worth knowing that you can create anonymous inner classes
derived from other classes too, they are solely for implementing Interfaces.

For example, you have a swing control that generates mouse events and
you want to have some code executed when the mouseEntered event is
generated.

You have a few choices.

You could:

1) create an anonymous inner class that implements the entire
MouseListener interface. However, as you are only interested in
mouseEntered() events, you'd be implementing lots of methods that do
nothing.

2) create an anonymous inner class that derives from the Abstract class
MouseAdapter which have all of the mouseListener interface methods
defined and you just need to over ride the one(s) you want - see
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/event/MouseAdapter.html

3) do either 1 or 2 above but using normal top level classes instead of
anonymous inner classes - works just the same.

HTH

Andrew
 
A

Andrew McDonagh

exquisitus said:
Chris Uppal wrote:

</snip>

WHY is everyone jumping to the conclusion that I am adverse to objects?.
I simply dont like the idea of spawning a new object (with all the
concomitant baggage) when a simple struct will do. I may not be up to
date with Java's latest performance figures etc, but coming from a
strong C++ (which allows you much more freedom - admitedly a double
edged sword if you dont know what you're doing), I must admit that I
view Java quite suspisiously when it comes to memory operations and
sheer performance - there I said it.

I can't speak for the others, but my own interpretation of your message
with regards to 'creating objects' was not one of 'oh god here's another
guy dishing Java'. It was more 'here's a guy using (IMO) a procedural
programming approach in an OO language (C++), and wanting to do the same
in Java'.

As a C++ developer, I've only ever resorted to this kind of approach you
mentioned when I have hard evidence of a performance problem with an OO
approach I have already developed. This evidence coming from a profiler.

Where as normally I favour Objects even in C++.

When developing (regardless of language) I favour getItWorking then
GetItWorkingFaster.

HTH to resolve some of the mis-communications happening here.
snipped

I must admit though that some of you guys
are *way* too sensitive about Java. It's just a language for Christ's
sake !.

Very true, but do take note of my comment above as I think others may be
of the same interpretation.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top