Page 1 of 2 12 LastLast
Results 1 to 20 of 36

Thread: static linking

  1. #1
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Question static linking

    { message edit: I'm gonna transition to "D" - this is not going anywhere
    this has been a great help but it is obvious that this will have to be written in "D" }

    { just google it ... }

    I am writing a dll called from Java Sources as native. Due to scope and reference management I would be able to sleep better if I could static link the c side functions that it calls into the dll and as well build the dll into the class file - static linkage also - so that end use issues deriving from "Unsatisfied Link Error" and where to place the dll do not arise. I will be doing good if I can get through Kimberley's Classfile Reader - Writer mentioned by Java Tips.

    It would really be adjunct to grasp how a class file stucture could be "hooked up" to a dll - my guess is to put everything in one directory during design / build / test then pack it in with a dot jar file and declare a main() class.....
    Last edited by Nicholas Jordan; 03-15-2009 at 01:11 AM. Reason: transitioning to another programing linguistic
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  2. #2
    DarrylBurke's Avatar
    DarrylBurke is offline Member
    Join Date
    Sep 2008
    Location
    Madgaon, Goa, India
    Posts
    11,236
    Rep Power
    19

    Default

    The system can't access the dll from inside a jar. This recent thread on the Sun forum may interest you:
    Java Programming - Java.library.path in manifest

    db

  3. #3
    Fubarable's Avatar
    Fubarable is offline Moderator
    Join Date
    Jun 2008
    Posts
    19,316
    Blog Entries
    1
    Rep Power
    26

    Default

    Never knew that, and great link. Thanks, Darryl!

  4. #4
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Question pointer scope and lifetime

    Okay, Darryl - I tried to give you points which I usually am more concerned with the code.

    dot dll is a system resource so it is not something that the jvm intends to do deep management on so it will not be exposed to sys os from within a dot jar..... good enough.

    Next queston, memory allocation .... constructing a Java Object from within the scope of the dll - uh, issues folks.

    The data type I get is well defined as void * into a BITMAPINFOHEADER - very base type: 8-bit greyscale, no compression - no fancy stuff. We then get into constructing the
    Java Code:
    private volatile java.awt.image.BufferedImage  ImageBuffer;
    on the dll side, and keeping the memory intact crossing the transition from one side to the other. Most examples pass something from Java source code into the loadable lib.

    Not so easy to pass a valid reference that will stay valid across invocations of native method calls, construction of the BufferedImage is not overly difficult in that there is a constructor taking two ints and a byte array. My first design considers using a static field on the Java Source Code side and holding a GlobalRef from the
    Java Code:
    __declspec(dllexport) jbyteArray __stdcall Java_ocr_zarf_zarf_1AcquireNative (JNIEnv * JEnvironmentPointer, jobject jayObject)
    entry point - the code of @author Sheng Liang and Johann Burkard though probably effective for a design goal, do work of passing of parameters at a skill level deeper that what I can safely work at.

    I could, I suppose pass a [B as the return value - setting an instance or static int for width and height and construct the BufferedImage on the Java side from a static DataBufferByte field set on the dll side - the docs state that a return from the call into the dll side will pop the stack with the return value in scope in the scope where the return returns to. Good enough, at least it sounds like it - then we get into the nasty business of * being a notational for what really needs to be some mild system engineering.

    Ref goes out of scope when the JNIEnv * goes out of scope, reasonable enough - exception is made for the return value: It's in scope in the stack frame that is used after the current {} is popped - okay, but I have to do
    Java Code:
    GlobalFree(bitMapHandle);
    I started coding a beefy copy-semantics code block, but that solves neither the size that should be passed to the constructor for the member instance or static BufferedImage variable nor the issue of the malloc return remaining valid as control passes from the dll back to the Java Source which called the native method.

    It would seem prima-facia that we can keep pointers valid as it is the thread from the Java code that is running that droped into the dll and as well is the same thread when it returns. Having to code where nothing stays in scope because too many zigarettes on the canvas canopy over Hopeless Hotel just really does not seem to be to be appropriate to robust code.

    Additionally, we have introduced an issue of obtaining the method ID for the constructor taking a string resolve the constructor signature. by passing a char * but when we do the actual call to run the constructor, all that the spec says is " ... "

    That's neither va_args nor [] - and most certainly that is not an int in a register.

    Never seen an int value == ... in source code, I would think I could load an int or long with three bytes of ascii "..." - but would be guessing: That is not appropriate for where this code needs to run.

    This is in the mesosphere folks, really - I have my hands full just trying to get past the lookup table and get the actual data-points.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  5. #5
    OrangeDog's Avatar
    OrangeDog is offline Senior Member
    Join Date
    Jan 2009
    Location
    Cambridge, UK
    Posts
    838
    Rep Power
    6

    Default

    By definition you cannot link a DLL statically, they are Dynamic-Link Libraries. To link statically you should compile to static object code (.o or somesuch) and a header (.h) to connect it via JNI.

    I find making native calls is not something one needs to be doing, unless you're building a JVM or something. With modern JVMs, there isn't really any significant speedup in native code due to overheads in dealing with the nasty memory management.

  6. #6
    toadaly is offline Senior Member
    Join Date
    Jan 2009
    Posts
    671
    Rep Power
    6

    Default

    Although you can't link a dll statically, you can effectively make it behave that way. What you do, is package everything together into a single executable jar file.

    The main class is not the class you want to launch, but is instead an extractor. The extractor pulls the well known dll(s) out of the jar file, puts it into a temporary directory, then launches the desired main class with PATH modified to include that temp directory.

    Ok, so now you have well defined behavior for your native package. Next, you want persitence for your native data within the JVM. The way you do that is to have what amounts to a constructor you call from Java, that returns a pointer to a 'new' native class. You then interact with your native code by always passing that pointer back through the JNI interface to maintain persistence. Override the finalize of your manager class to ensure the native destructor gets called when it's owner class goes out of scope.

    I don't know if this is the best approach the community would recommend, but I've used it countless times with no problems.

  7. #7
    toadaly is offline Senior Member
    Join Date
    Jan 2009
    Posts
    671
    Rep Power
    6

    Default

    Also, you may want to consider using stdin/out as pipes to communicate between a pure java process and a native process that is launched by Runtime.exec. JNI tends to be messy. If your native code is fairly well segmented from your java code, and you can live with the performance of this approach, I think you'll find it a much cleaner solution overall.

  8. #8
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Post placement

    Quote Originally Posted by OrangeDog View Post
    By definition you cannot link a DLL statically, they are Dynamic-Link Libraries. To link statically you should compile to static object code (.o or somesuch) and a header (.h) to connect it via JNI.
    I have not read the next post + I did some more reading and will be implementing the first JNI side call in the dll today, working ahead of my skill level: Given that I can install a JVM if need be + have total access to development and testing platform but may need to work within userland constraints later:
    compile to static object code (.o or somesuch) and a header (.h) to connect it via JNI.
    Make funcs static in dll? Link the dll into a build that includes sources for JVM - calling a JVM that is built in to an exe? Don't really know what to ask here but I sort of expect that calling an installed JVM can be done with shell links on the first machine - later I will not have any way to determine in advance what is going on and will have to run hands off so I figured to build the dll as a lib and bury it somewhere. Then call load library in a conventional manner, last thing I encountered was "RegisterNatives" and "InitIDs" not being visible in the manner I usually find things. I assumed these function addresses were in a running JVM - assume is not a good word.

    Quote Originally Posted by OrangeDog View Post
    I find making native calls is not something one needs to be doing, unless you're building a JVM or something. With modern JVMs, there isn't really any significant speedup in native code due to overheads in dealing with the nasty memory management.
    That is not the issue, examine the work of bahri.gencsoy in Comment#8 dated Apr 01, 2008 at Issue 93 - tesseract-ocr - TessDLL wraper for java - Google Code ... I am a few posts down at Comment 12 by fa8298b8, Jan 29, 2009

    This is work that is not currently implemented, I am working on the C side solely to get some calls implemented that are not available in any package I could find.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  9. #9
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Question pointer issues

    Quote Originally Posted by toadaly View Post
    Also, you may want to consider using stdin/out as pipes to communicate between a pure java process and a native process that is launched by Runtime.exec. JNI tends to be messy. If your native code is fairly well segmented from your java code, and you can live with the performance of this approach, I think you'll find it a much cleaner solution overall.
    It' gets deep trying to clarifiy what I am trying to accomplish - Process and Exec and so on seem to me to hark back to signals and some code that cannot seem to get away from the Interrupt Vector Table hanging the core of the machine in non-rentrant code, usually diving into near pointers SS != DS and it appears to me at my best efforts that doing the messy work needed can bring the data to 32-bit flat address space.

    Java Code:
    jclass localRefImageClass    = (*JEnvironmentPointer)->FindClass(JEnvironmentPointer,"Ljava/awt/image/DataBufferByte;");
    is an Another World compared to standing in front of Powerhouse Pinions on a Network Feed with a locked machine and Investors leaving like Flocking Boids....

    ( no intent to be difficult - this is where I am at == being direct )
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  10. #10
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Cool exactly the approach I am attempting

    Quote Originally Posted by toadaly View Post
    I don't know if this is the best approach the community would recommend, but I've used it countless times with no problems.
    This is exactly the approach I am dis-entangling - the only uncertain read I have on your reply is - " 'new' native class" ( ? ) - what the issue is here for me is that Java absolutely insists on going through IP - "File"s have to be thought of as an abstraction, keyboard work at the compiler and rutime become idempotent with char and int data types, where did the lowly byte fall off the wagon? Along with study of the work of https://jai-core.dev.java.net/ and the spec, one thing I will do today as a first things first is temp code:

    Java Code:
    private volatile int[] dataBlock=new int[(64 / 4)];// 4 byte per int - end up with 2048 bit .....
    to get a buffer that is of reasonable size and can be recoded to behave as a image data [] - and just totally get as far as I can for the moment from concepts of char and int ( numerics ) being an unavoidable overlay on efforts. Something akin to void* but with an apriori of 2048 raw data bits.

    This is a parallel with the work discussed in this thread.

    Quote Originally Posted by toadaly View Post
    The main class is not the class you want to launch, but is instead an extractor. The extractor pulls the well known dll(s) out of the jar file, puts it into a temporary directory, then launches the desired main class with PATH modified to include that temp directory.
    Using a JVM already installed on the machine or instantiating a JVM from the loaded lib?

    BTW - if I put the lib I am linking to in the compiler lib directory an only attempt to link to MD ( multi-threaded ) .... lost here, over my head but I dropped EZTwain.lib in the compiler directory and sort of figured if there was a namespace collision due to writing raw C code that it would show up in the first few runs as erratic behaviour and be obvious - that's not what spike told me to do.

    Quote Originally Posted by toadaly View Post
    Ok, so now you have well defined behavior for your native package. Next, you want persitence for your native data within the JVM. The way you do that is to have what amounts to a constructor you call from Java, that returns a pointer to a 'new' native class. You then interact with your native code by always passing that pointer back through the JNI interface to maintain persistence. Override the finalize of your manager class to ensure the native destructor gets called when it's owner class goes out of scope.
    Front end code already in place, what the issue here is for me is if I malloc in the dll and call things like:
    Java Code:
    jmethodID constructorzarfDataBuffer=(*JEnvironmentPointer)->GetMethodID(JEnvironmentPointer,localRefzarfObject,"<init>","([B,I)V");//
    does the mem* remain valid on the Java side? In other words, without doing attach to JVM and the other things I am reading, I want to alloc in the dll and have it show up ( correctly ) in the Java code. Things like having the destructory free and losing pointers on failed realloc's and so on is kindergarten level code concepts for me, I wish to leave the approach the community would recommend back with some other things I abandonded before enrolling in said kindergarten.

    My dad would relate stories about how bad it was to walk nearly a mile to a school house in Oklahoma, they were share croppers. I never figured it down, I demanded to walk a mile and a half to school at he age of 5, but of course I did not attempt to whup him like he did his dad at the age of ten or twelve because I could see that I was not big enough.

    I want to make sure my pointers are big enough, the do not have to be huge.

    { message edit: it would really be nice if I could call constructors on image buffers from the dll side, thus: }
    Java Code:
    jclass localRefImageClass    = (*JEnvironmentPointer)->FindClass(JEnvironmentPointer,"Ljava/awt/image/DataBufferByte;");
    jmethodID constructorDataBuffer = (*JEnvironmentPointer)->GetMethodID(JEnvironmentPointer,localRefImageClass,"<init>","V");
    jclass localRefzarfObject          = (*JEnvironmentPointer)->GetObjectClass(JEnvironmentPointer, jayObject);
    jclass localRefRasterClass         = (*JEnvironmentPointer)->FindClass(JEnvironmentPointer, "java/awt/image/Raster");
    jclass localRefBufferClass         = (*JEnvironmentPointer)->FindClass(JEnvironmentPointer, "java/awt/image/DataBufferByte");
    jclass localRefBufferedImageClass  = (*JEnvironmentPointer)->FindClass(JEnvironmentPointer, "java/awt/image/BufferedImage");
    jclass localRefByteLookupTableClass= (*JEnvironmentPointer)->FindClass(JEnvironmentPointer, "java/awt/image/ByteLookupTable");
    jfieldID localRefzarfMemberVar_1    =(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"availablity","I");
    jfieldID localRefzarfMemberVar_2    =(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"dataLength" ,"I");
    jfieldID localRefzarfMemberVar_3    =(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"dataBlock","[I");
    jfieldID localRefzarfMemberVar_4    =(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"byteArray","[I");
    jfieldID localRefzarfMemberVar_5    =(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"dataBufferByte","Ljava/awt/image/DataBufferByte;");
    jfieldID localRefzarfMemberVar_6    =(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"ImageBuffer","Ljava/awt/image/BufferedImage;");
    jmethodID constructorzarfDataBuffer =(*JEnvironmentPointer)->GetMethodID(JEnvironmentPointer,localRefzarfMemberVar_5,"<init>","([B,I)V");//
    jmethodID constructorzarfImageBuffer=(*JEnvironmentPointer)->GetMethodID(JEnvironmentPointer,localRefzarfMemberVar_6,"<init>","([B,I)V");//
    code is a step beyond the edge of my skills and may need fundamental work, what I am tring to do is call constructors on
    Java Code:
    private volatile int availablity=(-0xffff);
    private volatile int dataLength =(-0xffff);
    private volatile int [] dataBlock=new int[(64 / 4)];// 4 byte per int - end up with 2048 bit .....
    private volatile byte[] byteArray=new byte[0x00000000];//
    private volatile java.awt.image.DataBufferByte dataBufferByte= new java.awt.image.DataBufferByte(( new byte[0]),(int)0x00000000);// non-null field to avoid null pointer exceptions
    private volatile java.awt.image.BufferedImage  ImageBuffer;
    in the Java code, and do it from the dll side -- with "*" valid and in scope in the .java when the dll call returns.....without having to return individual data fields as the dll code goes out of scope on return unless one does thread.attach

    Much simpler if we can just run the constructors from the dll and then pass back to zarf.java
    Last edited by Nicholas Jordan; 03-02-2009 at 06:08 PM. Reason: buf size + post new code
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  11. #11
    OrangeDog's Avatar
    OrangeDog is offline Senior Member
    Join Date
    Jan 2009
    Location
    Cambridge, UK
    Posts
    838
    Rep Power
    6

    Default

    In order to call constructors in C/C++, use the FindClass and NewObject pointers in the JNIEvn * you're given. The heap allocation should work itself out so that the object you return to Java still exists once the native code has finished running.

  12. #12
    OrangeDog's Avatar
    OrangeDog is offline Senior Member
    Join Date
    Jan 2009
    Location
    Cambridge, UK
    Posts
    838
    Rep Power
    6

    Default Deployment

    If this is what you have implied - a wrapper for the tesseract-ocr system, the typical method of deployment is to include the JNI module with the tesseract binaries and get the user to configure the Java library when they use it to point to wherever they've installed the ocr system. As they'll need to download all the existing code anyway, there's no point including your native code in a jar rather than with the rest of the project.
    Last edited by OrangeDog; 03-02-2009 at 09:30 PM. Reason: clarify

  13. #13
    toadaly is offline Senior Member
    Join Date
    Jan 2009
    Posts
    671
    Rep Power
    6

    Default

    Quote Originally Posted by Nicholas Jordan View Post
    ... where did the lowly byte fall off the wagon?
    It's still there, but you have to access it through a directly allocated ByteBuffer, or by using the JNI array get/set/release methods.

    Using a JVM already installed on the machine or instantiating a JVM from the loaded lib?
    If you're writing native code, it's better to use a version of Java you've installed as part of your package - it's only disk space which is now effectively free. It doesn't need to be extracted from a jar file, but it does need to 'belong' to your application. Alternately, you can use jnlp (or something like it) to guarantee that the installed Java is compatible with your app.

    does the mem* remain valid on the Java side? In other words, without doing attach to JVM and the other things I am reading, I want to alloc in the dll and have it show up ( correctly ) in the Java code.
    It won't work unless you use the JVM to allocate it in the first place (using the NewObject methods). However, you can construct anything you want on the native side using that.

    If you want a native byte array to show up in Java, you can either construct a direct ByteBuffer and interract with it, or use the get/set/realease native array interface. Bus speeds have generally exceeded CPU speeds now, so memcpy is no longer much of a performance issue like it was in days of old.

    Things like having the destructory free and losing pointers on failed realloc's and so on is kindergarten level code concepts for me, I wish to leave the approach the community would recommend back with some other things I abandonded before enrolling in said kindergarten.
    heh. The nice thing is, if you create a Java class to parallel every native class, you can use the finally method of the Java class to call the native destructor. No memory leaks. Of course, if you take this approach, you can not allow your native classes to directly interract with eachother (except through JNI) or you'll end up with something trying to access something that's alreayd been free'd - a seg fault in unix/linux or the infamous 'General protection fault' on windows.

    I want to make sure my pointers are big enough, the do not have to be huge.
    Use Java long's (long long on most native platforms). They will be adequate to represent all memory for the forseeable future, even accounting for a doubling every 1.5 years. It doesn't matter how much memory your app uses, what matters is that you cover all possible address spaces your OS might assign to you.

    Much simpler if we can just run the constructors from the dll and then pass back to zarf.java
    I guess I'm missing something. You can pass Objects you created in native code (using the JVM) back up the call chain to Java. The JNI interface is cumbersome, but it does allow this.

    By the way, you are probably aware that there are 2 ways of using JNI. The first is what you've been describing - start up a JVM and let it make calls to your native libraries. This is a good approach when your native code is short lived; you make a call, it does something, dies and returns.

    If you need native persistence, you can use the tricks we've been discussing, or you might consider having your 'main' be a native application that constructs your JVM. With this approach, Java acts much like any other native library. You can still use it to construct your GUI, use its sound API or whatever else it is you need it for, but it simplifies native code issues. But, I would only take that approach if you are already well versed in c++.

  14. #14
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Thumbs up Your really have me scoped for now.

    I would only take that approach if you are already well versed in c++.
    This is good, few people can understand me unless they have at least a Master's in cs and 5+ years field experience - more like 30,000 hours to do what you are doing - I tried writing several files scope statics yesterday, never got past the pointer casting errors.

    I already boilerplated the finally to do the GlobalFree - I have one entrance on the Java side, pulled headers with javap ... chose "C" rather than CPP as ( CPP ) hides some issues: I need to know what is going on. I tired to construct the BufferedImage declared on the Java side from the dll side yesterday - got too involved but I did get a constructor for a Byte Buffer to compile:
    Java Code:
    jclass localRefDataBufferByteClass =(*JEnvironmentPointer)->FindClass(JEnvironmentPointer,"Ljava/awt/image/DataBufferByte;");
    DataBufferByteConstructor=(*JEnvironmentPointer)->GetMethodID(JEnvironmentPointer,localRefDataBufferByteClass,"<init>","([B,I)V");
    jfieldID localRefzarfMemberVar_7=(*JEnvironmentPointer)->GetFieldID(JEnvironmentPointer,localRefzarfObject,"dataBufferByte","Ljava/awt/image/DataBufferByte;");
    but had to stop at finding set Object == new ( run constructor ) as I had been at it for 12 hours and lost traction.

    It's early, there is a lot in your post - I will work on this for ten or so hours and get back with what I come up with.

    { message edit: "I guess I'm missing something." - hidden blowouts not unlike the jit optimization that can cause a rare failure by statement re-ordering. ( since corrected in recent releases )}
    Last edited by Nicholas Jordan; 03-03-2009 at 01:29 PM.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  15. #15
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Post casts

    Quote Originally Posted by OrangeDog View Post
    In order to call constructors in C/C++, use the FindClass and NewObject pointers in the JNIEvn * you're given. The heap allocation should work itself out so that the object you return to Java still exists once the native code has finished running.
    I got a pointer casting error I did not understand, Java seemed to need a long, which I was unsure how to verifiy that would be used as a pointer rather than some offset that I did not have full grasp of.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  16. #16
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Post Neural Networks - research

    Quote Originally Posted by OrangeDog View Post
    If this is what you have implied - a wrapper for the tesseract-ocr system, the typical method of deployment is to include the JNI module with the tesseract binaries and get the user to configure the Java library when they use it to point to wherever they've installed the ocr system. As they'll need to download all the existing code anyway, there's no point including your native code in a jar rather than with the rest of the project.
    The tesseract wrapper mention was to get in scope what I am trying to do. I wish to write the entire thing so that I do not end up installing someone else's binaries on a machine that the customer can come to me asking what happend. Classic case of they might have printf blow out or something, no way to set the compiler switches and so on. What I really want to do is get the raw data out of the dib, which is known to be an 8-bit greyscale standard dib - then pass that data to Java and do work under Jeff Heaton's "Introduction to Neural Networks"

    We see plenty of posts here where someone is trying to dig out of a bust in a proprietary package and there is no way to get at the sources. I realize tesseract is available in the wild, but I read the c sources and what I see at the core is what I am trying to get away from. If I could just extract the raw [] and pass that to the JVM then that is what the underlying purpose of the post is, by static linking - I actually had a floor of getting away from some issues that I am not able to determine by reading someone else's code and loading a lib that I did not build on a customer machine.

    Some will discount my efforts, been on the end of that too many times.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  17. #17
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Talking Holzgedackt 8

    Here, todaly - have some fun, first draft:
    Java Code:
    (*JEnvironmentPointer)->SetByteArrayRegion(JEnvironmentPointer,(jbyteArray)localRefzarfMemberVar_6,(jsize)0x00000000,(jsize)sizeof(buffer64),(_jbyteArray)imageMemoryReference);
    Roll Holzgedackt 8, Cue: Fog machine:

    Is imageMemoryReference cast to a _jbyteArray ( which is a subclass of _jarray which is sublcass of _jobject - ultimate root of the native side typing system) or is it cast to a jbyteArray ( which is a pointer to a _jarray object ) ?

    And, for Quiz Time - what error(s) will the compiler produce.

    And, for angryboy: How do we eliminate the compiler insisting on determining the content of the buffer to be unsigned char ( or possibly a pointer to unsigned char ) when I don't care if the characters dance to "Opus 67", designed and built by Abbott and Sieker of Los Angeles, I need 812 pipes, separated into three divisions:
    • Raw data blocks.
    • L-2 access without file semantics.
    • No writebacks on AVL Tree of Zero Page Thread unless I ask for them.

    Hint, this is not commercially available except as FFT, and no drilling into the IVT ( ! )
    Hint #2: use Surreal numbers ( a mathematical novelette ): (1974) ISBN 0-201-03812-9, by Donald Ervin Knuth a mathematical instruction older than dirt on John Conway's set theory construction considering an alternate system of numbers to be used in battles against the curse of dimesionality.
    Last edited by Nicholas Jordan; 03-04-2009 at 04:41 PM.
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

  18. #18
    OrangeDog's Avatar
    OrangeDog is offline Senior Member
    Join Date
    Jan 2009
    Location
    Cambridge, UK
    Posts
    838
    Rep Power
    6

    Default

    If you're trying to re-write the libraries in Java then write them in Java, don't try and fudge together C and Java.

    Also, I would strongly recommend against trying any serious object manipulation in a flat imperative language like C, that is what C++ was "designed" for (C# would be better).

    If you've got an error message you don't understand then post, otherwise we can't help. If you're passing an object up through JNI, then the types have to match just as within Java calls. e.g. if you construct a ByteBuffer in C++ and return it, then Java will expect a ByteBuffer, not a long pointer address.

    It would also help people to understand your posts if you didn't use industry-specific jargon or relate anecdotes about your dad. Not everyone has a masters and 5 years field experience.

  19. #19
    toadaly is offline Senior Member
    Join Date
    Jan 2009
    Posts
    671
    Rep Power
    6

    Default

    Quote Originally Posted by Nicholas Jordan View Post
    Here, todaly - have some fun, first draft:
    Java Code:
    (*JEnvironmentPointer)->SetByteArrayRegion(JEnvironmentPointer,(jbyteArray)localRefzarfMemberVar_6,(jsize)0x00000000,(jsize)sizeof(buffer64),(_jbyteArray)imageMemoryReference);
    Roll Holzgedackt 8, Cue: Fog machine:

    Is imageMemoryReference cast to a _jbyteArray ( which is a subclass of _jarray which is sublcass of _jobject - ultimate root of the native side typing system) or is it cast to a jbyteArray ( which is a pointer to a _jarray object ) ?
    You should be casting imageMemoryReference (which should be a native array type such as signed char*) to a jbyte*, not a _jbyteArray. Also, don't forget to call ReleaseByteArrayElements at some point, so that the changes you made will be reflected on the java side. If you fail to do that, you'll have a heck of a time trying to figure out why the byte[] on the java side is always full of 0's.

    Quote Originally Posted by Nicholas Jordan View Post
    And, for Quiz Time - what error(s) will the compiler produce.
    I'm guessing it'll complain about what I just said (if you're lucky).

  20. #20
    Nicholas Jordan's Avatar
    Nicholas Jordan is offline Senior Member
    Join Date
    Jun 2008
    Location
    Southwest
    Posts
    1,018
    Rep Power
    8

    Thumbs up nope,

    Quote Originally Posted by toadaly View Post
    .....I'm guessing it'll complain about what I just said (if you're lucky).
    not really, eranga keeps the complianers up front as tools to work with showing deep internals such as those shown by Sedgewick's Strange.java

    I will work on the advice you provide, I got no end of linker errors yesterday and the lib "vendor" ( almost open source ) does not have the time to rebuild the lib to my specs...

    Java Code:
    // This is the ultimate goal of what I am trying to resove:
    
    OPTLINK : Warning 174: 32-bit Segments Inappropriate for 16-bit Segmented output 
    zarfDLL.obj(zarfDLL) 
     Error 35: Cannot Reach TARGET from FRAME at Relative 0001DH  from
     Segment _TEXT
     FRAME  = Frame of Group FLAT 0000
     TARGET = Segment _BSS 01454H 
     FIXUPP Type = 32-bit Offset
    Document1.txt - by attachment - is the full error report from the first build that I hoped to gain some traction on fully cleaning all near calls from the code.
    Attached Files Attached Files
    Introduction to Programming Using Java.
    Cybercartography: A new theoretical construct proposed by D.R. Fraser Taylor

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 3
    Last Post: 03-20-2009, 12:35 AM
  2. Non-Static method in static context error
    By wizmang in forum New To Java
    Replies: 4
    Last Post: 04-24-2008, 08:51 AM
  3. Replies: 0
    Last Post: 04-16-2008, 11:07 PM
  4. Replies: 1
    Last Post: 08-07-2007, 05:05 AM
  5. Replies: 1
    Last Post: 08-01-2007, 09:25 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •