From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn@satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn@satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx@linuxgrrls.org Cc: awaisa@hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 14 23:21:44 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx@linuxgrrls.org > Cc: awaisa@hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn@satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn@satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0001.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0001.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx@linuxgrrls.org Cc: awaisa@hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 28 18:25:03 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx@linuxgrrls.org > Cc: awaisa@hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn@satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn@satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0002.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0002.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx@linuxgrrls.org Cc: awaisa@hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx@linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Tue Mar 28 20:17:04 2006 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx@linuxgrrls.org > Cc: awaisa@hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces@linuxgrrls.org [mailto:rxtx-bounces@linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0003.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0003.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0004.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0004.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0005.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0005.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0006.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0006.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0007.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0007.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0008.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0008.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0009.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0009.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0010.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0010.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0011.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0011.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0012.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0012.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0013.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0013.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0014.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0014.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0015.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0015.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0016.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0016.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0017.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0017.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0018.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0018.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0019.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0019.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0020.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0020.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0021.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0021.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0022.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0022.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0023.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0023.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0024.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0024.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0025.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0025.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0026.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0026.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0027.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0027.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0028.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0028.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0029.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0029.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0030.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0030.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0031.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0031.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0032.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0032.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0033.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0033.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0034.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0034.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0035.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0035.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0036.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0036.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0037.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0037.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0038.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0038.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0039.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0039.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0040.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0040.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0041.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0041.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0042.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0042.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0043.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0043.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0044.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0044.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0045.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0045.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0046.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0046.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0047.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0047.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0048.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0048.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0049.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0049.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0050.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0050.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0051.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0051.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0052.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0052.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0053.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0053.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0054.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0054.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0055.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0055.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0056.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0056.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0057.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0057.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0058.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0058.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0059.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0059.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0060.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0060.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0061.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0061.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0062.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0062.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0063.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0063.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0064.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0064.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0065.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0065.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0066.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0066.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0067.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0067.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0068.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0068.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0069.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0069.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0070.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0070.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0071.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0071.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0072.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0072.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0073.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0073.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0074.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0074.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0075.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0075.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0076.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0076.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0077.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0077.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0078.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0078.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0079.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0079.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0080.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0080.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0081.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0081.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0082.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0082.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0083.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0083.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0084.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0084.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0085.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0085.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0086.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0086.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0087.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0087.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0088.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0088.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0089.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0089.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0090.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0090.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0091.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0091.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0092.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0092.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0093.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0093.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0094.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0094.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0095.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0095.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0096.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0096.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0097.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0097.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0098.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0098.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0099.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0099.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0100.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0100.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0101.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0101.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0102.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0102.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0103.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0103.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0104.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0104.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0105.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0105.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0106.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0106.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0107.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0107.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0108.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0108.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0109.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0109.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0110.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0110.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0111.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0111.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0112.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0112.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0113.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0113.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0114.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0114.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0115.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0115.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0116.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0116.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0117.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0117.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0118.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0118.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0119.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0119.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0120.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0120.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0121.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0121.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0122.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0122.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0123.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0123.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0124.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0124.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0125.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0125.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0126.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0126.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0127.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0127.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0128.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0128.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0129.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0129.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0130.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0130.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0131.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0131.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0132.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0132.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0133.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0133.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0134.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0134.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0135.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0135.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0136.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0136.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0137.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0137.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0138.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0138.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0139.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0139.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0140.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0140.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0141.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0141.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0142.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0142.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0143.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0143.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0144.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0144.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0145.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0145.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0146.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0146.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0147.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0147.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0148.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0148.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0149.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0149.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0150.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0150.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0151.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0151.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0152.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0152.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0153.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0153.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0154.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0154.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0155.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0155.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0156.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0156.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0157.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0157.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0158.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0158.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0159.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0159.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0160.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0160.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0161.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0161.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0162.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0162.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0163.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0163.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0164.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0164.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0165.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0165.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0166.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0166.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0167.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0167.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0168.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0168.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0169.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0169.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0170.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0170.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0171.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0171.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0172.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0172.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0173.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0173.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0174.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0174.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0175.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0175.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0176.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0176.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0177.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0177.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0178.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0178.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0179.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0179.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0180.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0180.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0181.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0181.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0182.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0182.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0183.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0183.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0184.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0184.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0185.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0185.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0186.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0186.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0187.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0187.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0188.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0188.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0189.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0189.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0190.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0190.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0191.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0191.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0192.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0192.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0193.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0193.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0194.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0194.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0195.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0195.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects are doing it. 1) Extract the correct .dll or .so to your current director, depending on platform 2) Read said library with System.load( currentDir + libName ); 3) done The System.load call doesn't rely on java library path, just on absolute filesystem location. if the library is extracted to the current directory, no directory or path issues will appear. If you find this inadequate to include in rxtx itself, please consider adding a boolean flag to define wether or not RXTX will call System.loadLibrary, so that people wanting to use the scheme above can do it outside RXTX. thanks Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Awais Ahmed Enviada: quinta-feira, 10 de Julho de 2003 20:25 Para: rxtx at linuxgrrls.org Cc: awaisa at hotmail.com Assunto: Re: [Rxtx] loading .dll or .so from jar Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From taj at linuxgrrls.org Fri Jul 11 04:46:30 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Fri, 11 Jul 2003 11:46:30 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: The pdf solution is fairly easy to implement but does involve installing native libraries. The security... OK. Lets start with Unix which I'm more familiar with than w32. There are two places these files would be allowed to be extracted: ~/ (the users home directory such as /home/jarvi /tmp /usr/tmp /usr/local/tmp - one of the tmp directories When applications do this they usually use a dot directory. If its in a tmp directory then cleanup is expected to be done afterwards. Lets just look at the home directory. /home/jarvi/.rxtx The home direcotry could be shared across multiple OS's and archs via NFS, SMB, ... so there would have to be subdirecotries for OS and arch. solaris/i386 for instance. Writing to the system/jre/jdk directories would be bad form and users will typically not have permission anyhow. In order for this to automatically happen, The lockfile feature would have to be disabled. This means a person using this library could open say a modem being used by another user and interfere with communications. I'm not sure at all what would be acceptable in a modern NT environment. Does anyone know what would be done as a user on say w2003? There are probably simular issues and solutions. On Fri, 11 Jul 2003, Ricardo Trindade wrote: > Hi, > > Why all this complication ? It's so easy. Have you read the pdf and .java I > posted ? That's the way several projects are doing it. > > 1) Extract the correct .dll or .so to your current director, depending on > platform > 2) Read said library with System.load( currentDir + libName ); > 3) done > > The System.load call doesn't rely on java library path, just on absolute > filesystem location. if the library is extracted to the current directory, > no directory or path issues will appear. > > If you find this inadequate to include in rxtx itself, please consider > adding a boolean flag to define wether or not RXTX will call > System.loadLibrary, so that people wanting to use the scheme above can do it > outside RXTX. > > thanks > Ricardo > > -----Mensagem original----- > De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > nome de Awais Ahmed > Enviada: quinta-feira, 10 de Julho de 2003 20:25 > Para: rxtx at linuxgrrls.org > Cc: awaisa at hotmail.com > Assunto: Re: [Rxtx] loading .dll or .so from jar > > > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From glenn at satlantic.com Wed Jul 9 14:17:24 2003 From: glenn at satlantic.com (Glenn Davidson) Date: Wed, 09 Jul 2003 17:17:24 -0300 Subject: [Rxtx] ClassCastException using RXTX 2.1-6 Message-ID: <3F0C7854.9000003@satlantic.com> I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: "Caught java.lang.ClassCastException while loading driver gnu.io.RXTXCommDriver" Does any onyone recognize this problem? -- Glenn Davidson |*| Phone: (902)492-4780 Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com From taj at linuxgrrls.org Wed Jul 9 14:25:38 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Wed, 9 Jul 2003 21:25:38 +0100 (BST) Subject: [Rxtx] ClassCastException using RXTX 2.1-6 In-Reply-To: <3F0C7854.9000003@satlantic.com> References: <3F0C7854.9000003@satlantic.com> Message-ID: This error is reported to the list now and then. I just looked through my email and the only thing I saw was that this does happen when the native library is unable to load. hmm. what do you have in .../java/jre/lib/i386/ If you did an install from source, there should be librxtxSerial-2.1-7pre16.so librxtxSerial.so (symbolic link to the above) Make sure you do not mix rxtx 2.1 with Sun's comm.jar and rxtx 2.0 jcl.jar On Wed, 9 Jul 2003, Glenn Davidson wrote: > I am using Java 1.4.1 on RedHat Linux (version 9) I currently have installed rxtx 2.1.6 and when my application runs I get the error: > > "Caught java.lang.ClassCastException while loading driver > gnu.io.RXTXCommDriver" > > Does any onyone recognize this problem? > > -- > Glenn Davidson |*| Phone: (902)492-4780 > Satlantic Inc., Richmond Terminal, Pier 9 |*| Fax: (902)492-4781 > 3295 Barrington St., Halifax, NS, Canada |*| E-mail: glenn at satlantic.com > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Thu Jul 10 11:35:04 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 18:35:04 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx From ricardo.trindade at emation.pt Thu Jul 10 12:02:25 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Thu, 10 Jul 2003 19:02:25 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: I'm replying to myself to add two attachments interesting to this issue : The .java is from the JUGS project. -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Ricardo Trindade Enviada: quinta-feira, 10 de Julho de 2003 18:35 Para: Java RXTX discussion Assunto: RE: [Rxtx] loading .dll or .so from jar I've looked this article up on the net, which explains the concept. I implemented it, but found an issue regarding the native lib. I load the library with System.load, but an exception is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the library on java.library.path. So I imagine that for this to be possible you would have to handle the loading with System.load, as stated in the article, or accept an argument to not load the library. What do you think of this ? Ricardo -----Mensagem original----- De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em nome de Trent Jarvi Enviada: segunda-feira, 7 de Julho de 2003 1:45 Para: Java RXTX discussion Assunto: Re: [Rxtx] loading .dll or .so from jar On Mon, 7 Jul 2003, Ricardo Trindade wrote: > Hi, > > Hi was wondering if you haver considered including the .dll and .so in the > jar, and loading the adequate one depending on the platform. > > Is this even possible ? > > It would also make life easier for rxtx begginners. The only drawback I see > is the increase in jar size, but people concerned about that could always > delete it. Also with tens of megs of JRE it's hardly a problem for any java > user... > Hi Ricardo Thats a great idea. Have you done something like this before? I can picture everything required except for the native library paths. Thats probably doable also. That certainly would simplify installs. _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at linuxgrrls.org http://hex.linuxgrrls.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: nativelibs.pdf Type: application/pdf Size: 72425 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/nativelibs-0196.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: NativeLibs.java Type: text/x-java Size: 7537 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20030710/46bcf03a/NativeLibs-0196.bin From awaisa at hotmail.com Thu Jul 10 13:25:20 2003 From: awaisa at hotmail.com (Awais Ahmed) Date: Thu, 10 Jul 2003 19:25:20 +0000 Subject: [Rxtx] loading .dll or .so from jar Message-ID: Hello All, I guess the first question is: if it is possible. The answer is *NO*. I am not aware of any support like this from Suns JVM implementation. All JNI based shared libraries are loaded in the following flow of functional execution. 1. Java Application somewhere requests to load a native library. Using calls like System.loadLibrary(""). Normally this is done in some static initializers 2. Later, defining class loader of the class containing loadLibrary Call invokes a one of its JNI *native* function to load a library. 3. That particular native system library requests JVM to load the requested library, which is then loaded through the dynamic loader. Now to make it happen, one will have to consider security issues and see how to add support to extract a native library from a jar and place it in some location/path which could later be made accessible to the dynamic loader to load. And this again has an issue. Currently, I am not aware of any scenario where a JVM creates any executible code file anywhere in your secondary location. Anything that is generated is mapped on memory and is all dynamic. Introducing a system library would be a new thing. Note: It's it important to have a library be loaded through some VM as then VM will be responsible for unloading that library if it's no more referenced. Now I can think of folowing ways: 1. You create your own objects that makes use of packages like java.util.jar or java.util.zip or some other custom components and extract the native libraries at some location and then modify java.library.path and then let System.loadLibrary play it trick. It is a little ugly as one also will have to keep in mind some files cleanup mechanism. 2. An ideal way (may not be in your control to do it) could be: Have the VM do it totally and issues would be: Since dynamic loader also has a major role in loading a library, which has to have some physical existance accessible through some path. And there are issues and concerns if VM will create a new file with executible code in a disk-space. As any runtime code should only be laid out in memory. (Note it's not accesptable to have VM create/introduce any new native code based files) One option that makes it do-able is if dynamic loader gives an interface to load a library from memory. In this scenario VM could extract the system library bits and map it in some memory and let the dynamic loader accept executible code from memory. One can try it on some research VMs along with some adding some support in dynamic loader. Awais Sheikh PS: I am not sure if this email will go through as I am not sending it through my registered email address. ----- Original Message ----- From: "Ricardo Trindade" To: "Java RXTX discussion" Sent: Thursday, July 10, 2003 10:35 AM Subject: RE: [Rxtx] loading .dll or .so from jar >I've looked this article up on the net, which explains the concept. > >I implemented it, but found an issue regarding the native lib. I load the >library with System.load, but an exception >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the >library on java.library.path. So I imagine that for this to be possible you >would have to handle the loading with System.load, as stated in the >article, >or accept an argument to not load the library. > >What do you think of this ? > >Ricardo > >-----Mensagem original----- >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em >nome de Trent Jarvi >Enviada: segunda-feira, 7 de Julho de 2003 1:45 >Para: Java RXTX discussion >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > Hi, > > > > Hi was wondering if you haver considered including the .dll and .so in >the > > jar, and loading the adequate one depending on the platform. > > > > Is this even possible ? > > > > It would also make life easier for rxtx begginners. The only drawback I >see > > is the increase in jar size, but people concerned about that could >always > > delete it. Also with tens of megs of JRE it's hardly a problem for any >java > > user... > > > >Hi Ricardo > >Thats a great idea. > >Have you done something like this before? I can picture everything >required except for the native library paths. Thats probably doable also. > >That certainly would simplify installs. _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From taj at linuxgrrls.org Thu Jul 10 14:39:28 2003 From: taj at linuxgrrls.org (Trent Jarvi) Date: Thu, 10 Jul 2003 21:39:28 +0100 (BST) Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: References: Message-ID: Yikes. It may be more productive to look at an installer rather than gowing down one of these directions. It would not be too hard to extract the proper binary from a jar file and place it in the correct location. Same for the comm.jar. If we start creating directories, dumping files, looking at VM hacks, and so forth, we will get in trouble one way or another. On Thu, 10 Jul 2003, Awais Ahmed wrote: > Hello All, > I guess the first question is: if it is possible. > The answer is *NO*. I am not aware of any support > like this from Suns JVM implementation. > All JNI based shared libraries are loaded in the > following flow of functional execution. > 1. Java Application somewhere requests to load a > native library. Using calls like > System.loadLibrary(""). Normally this > is done in some static initializers > 2. Later, defining class loader of the class > containing loadLibrary Call invokes a one of its > JNI *native* function to load a library. > 3. That particular native system library requests > JVM to load the requested library, which is then > loaded through the dynamic loader. > > Now to make it happen, one will have to consider > security issues and see how to add support to > extract a native library from a jar and place it > in some location/path which could later be made > accessible to the dynamic loader to load. And this > again has an issue. Currently, I am not aware of > any scenario where a JVM creates any executible > code file anywhere in your secondary location. > Anything that is generated is mapped on memory > and is all dynamic. Introducing a system library > would be a new thing. > > Note: It's it important to have a library be > loaded through some VM as then VM will be > responsible for unloading that library if it's > no more referenced. > > Now I can think of folowing ways: > 1. You create your own objects that makes use of > packages like java.util.jar or java.util.zip > or some other custom components and extract the > native libraries at some location and then > modify java.library.path and then let > System.loadLibrary play it trick. It is a > little ugly as one also will have to keep in > mind some files cleanup mechanism. > > 2. An ideal way (may not be in your control to > do it) could be: > Have the VM do it totally and issues would be: > Since dynamic loader also has a major role > in loading a library, which has to have some > physical existance accessible through some path. > And there are issues and concerns if VM will > create a new file with executible code in a > disk-space. As any runtime code should only be > laid out in memory. (Note it's not accesptable > to have VM create/introduce any new native code > based files) One option that makes it do-able > is if dynamic loader gives an interface to load > a library from memory. In this scenario VM could > extract the system library bits and map it in > some memory and let the dynamic loader accept > executible code from memory. > One can try it on some research VMs along with > some adding some support in dynamic loader. > > Awais Sheikh > > PS: I am not sure if this email will go through as > I am not sending it through my registered email > address. > > ----- Original Message ----- > From: "Ricardo Trindade" > To: "Java RXTX discussion" > Sent: Thursday, July 10, 2003 10:35 AM > Subject: RE: [Rxtx] loading .dll or .so from jar > > > >I've looked this article up on the net, which explains the concept. > > > >I implemented it, but found an issue regarding the native lib. I load the > >library with System.load, but an exception > >is thrown on you System.loadlibrary("rxtxSerial"), saying I don't have the > >library on java.library.path. So I imagine that for this to be possible you > >would have to handle the loading with System.load, as stated in the > >article, > >or accept an argument to not load the library. > > > >What do you think of this ? > > > >Ricardo > > > >-----Mensagem original----- > >De: rxtx-bounces at linuxgrrls.org [mailto:rxtx-bounces at linuxgrrls.org]Em > >nome de Trent Jarvi > >Enviada: segunda-feira, 7 de Julho de 2003 1:45 > >Para: Java RXTX discussion > >Assunto: Re: [Rxtx] loading .dll or .so from jar > > > > > > > > > >On Mon, 7 Jul 2003, Ricardo Trindade wrote: > > > > > Hi, > > > > > > Hi was wondering if you haver considered including the .dll and .so in > >the > > > jar, and loading the adequate one depending on the platform. > > > > > > Is this even possible ? > > > > > > It would also make life easier for rxtx begginners. The only drawback I > >see > > > is the increase in jar size, but people concerned about that could > >always > > > delete it. Also with tens of megs of JRE it's hardly a problem for any > >java > > > user... > > > > > > >Hi Ricardo > > > >Thats a great idea. > > > >Have you done something like this before? I can picture everything > >required except for the native library paths. Thats probably doable also. > > > >That certainly would simplify installs. > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://hex.linuxgrrls.org/mailman/listinfo/rxtx > From ricardo.trindade at emation.pt Fri Jul 11 03:46:11 2003 From: ricardo.trindade at emation.pt (Ricardo Trindade) Date: Fri, 11 Jul 2003 10:46:11 +0100 Subject: [Rxtx] loading .dll or .so from jar In-Reply-To: Message-ID: Hi, Why all this complication ? It's so easy. Have you read the pdf and .java I posted ? That's the way several projects