Hi Jochen,
well I have a lots to say you.
all good news, I think we speed up VJDK a little now.
1) download paradigma/download/VSDK_PPC_beta2.sit.bin
-------------------------------------------------------------
2) in all classes VDK_ field, cursor, database, baseobject I have
add
public:
VDK_xxxx** mBaskRef.
so now you can set in VJDK this backref and IF C++ instance is destroyed BY
KERNEL then it will set pointer on self in VJDK to NULL.
In VJDK code you need add protection
if( p ){
...
}
Now question WHERE you store pointer on VDK_Field, for example.
as I see you put it into field m_ptrImp:
t_field = env->GetFieldID( t_jcl, "m_ptrImp", "I" );
env->SetIntField( t_oResult, t_field, jint(a_ptrField) );
As I understand we DO NOT have access to memory of that field,
so you should change a little code. Exactly as we do this in V4RB plugin.
For Each class as VField I make small C++ struct
struct FieldData
{
VDK_Field* mData;
}
and inside java object we store pointer on THIS struct.
Inside of this struct you store pointer on VDK object.
FieldData* pd = new FieldData;
pd->mDataField = a_ptrField;
a_ptrField->mBackRef = pd->mDataField;
env->SetIntField( t_oResult, t_field, jint(pd) );
------------------------------------------------------------------------
3) in all that VDK classes I have add new data member
void* mXtraData;
I did want add it far along.
Very handy I think. It allow us attach to c++ instance any data we want of
any size.
In VJDK case we can store here pointer on jobject.
You see what this means ?!
Go away:
a) 3 map where you link java and C++ objects.
b) you use map.Find() to find java object related to C++ object.
NOW you can get java object in NOT TIME!!!
Cool, yes ? :-)
---------------------------------------------------------------------------
4) Jochen, I see that in many places you do:
jstring t_sName = env->NewStringUTF( t_strName );
t_field = env->GetFieldID( t_jcl, "m_Name", "Ljava/lang/String;" );
env->SetObjectField( t_oResult, t_field, t_sName );
as far as I understand for a Java class, e.g. VField
and for its field, e.g. mName, m_ptrImp and so on
ID of field IS THE SAME ALWAYS during runtime.
If this is true, and I believe this is true,
you can set up 20-30 global variables and init them on call ValentinaInit()
so later you will do just
env->SetObjectField( t_oResult, gVField_Name, t_sName );
we save to calls to Java environment!!!
and this calls looks to be not slow enough.
Do you like this ?
-------------------------------------------------------------------------
5) and at last about constructors and destructors.
If you looks into V4RB sources you will see that I have
1 destructor in class VField
NO constructor in class VField
constructors ONLY in classes VByte, VShort, ...
I think in VJDK we also should/must/can such structure of functions.
For example right now I believe function
Java_com_paradigmasoft_valentina_vjdk_VField_NewVField()
is NEVER called, because we never create just VField.
In the same time It looks enough to have destructor onlty in VField
constructor which will do the same for all classes
FieldData* pd = extract from java object
delete pd->mDataField;
check this but in last turn.
Well you have a lots TODO :-)
--
Best regards,
Ruslan Zasukhin
-------------------------
Paradigma.
e-mail: ruslan .at. paradigmasoft D.O.T com
web : http://www.paradigmasoft.com
To subscribe to the Valentina mail list
send a letter to valentina-on@lists.macserve.net
©2001 Ruslan Zasukhin |
