Reputation: 21
I have a Java program that correctly accessed a serial port on Windows XP, and am trying to get it working on my Windows 7 (Home Premium) box. I am developing in Eclipse.
The program currently uses rxtx classes. My original download (for xp) appears to be 32-bit specific, so I have gotten the Cloudhopper 64-bit implementation and put it in the indicated directories (to the extent that they matched the installation instructions) and added the jar as an external jar to my project.
I now have the following error on any use of classes from the rxtx jar:
The field X from the type Y is not accessible due to a restriction on the required library c:\Program Files\Java\jre6\lib\ext\RXTXcomm.jar
What I've found on the error is that the access restriction has something to do with the Java licensing agreement; all of these classes are outside the java package so I don't understand what that problem is. I would like to, though if I can solve the problem without understanding it I suppose I will.
I have found several forum posts, none more recent than a couple of years ago, purporting to solve the problem by
eliminating the JRE library from the build path and re-adding it. This had no effect in my case.
eliminating the error in the eclipse preferences for errors and warnings; again, no help.
I have found a commercial package that might be able to do this for hundreds of dollars, but I'm just working on a project of my own that will probably never generate any revenue, and so it isn't worth hundreds of dollars to me to buy something for the purpose. Besides, it seems like something in the open-source community is so close.
So my question has two levels:
Can someone help me with the access restriction on Cloudhopper's rxtx implementation, for Java 6 in eclipse Indigo?
Is there another way to access serial ports on Windows 7 using Java that is easier/better/at-least-doesn't-have-access-restriction-problems?
Upvotes: 1
Views: 3440
Reputation: 1
Windows -> Preferences -> Java Compiler
Upvotes: 0
Reputation: 21
I think now it must have been the fact that this non-java-package library was in the JRE's space, though I haven't verified that. Anyway, I moved it out and then, after having noticed that the things I thought were errors in one project were errors in a different project, caused by the fact that the second project did not list this as a library it needed, that helped a lot.
There do turn out to be a couple of minor differences between this one and the 32-bit one I had earlier -- took 15-30 minutes to straighten out with eclipse's help -- but I am now reading my device!
Upvotes: 1
Reputation: 12766
From what you've described, this sounds like the standard compiler error when using a sun.* package. I've had it happen to me when working on a program that reused Sun's Base64 classes.
Basically, you're accessing the internals of the JRE -- which are not required to stay consistent between releases, and not meant to be accessed by developers outside of Sun/Oracle. You can disable this error in Eclipse, or downgrade it to a warning, but it's warning you for a good reason. If you change it to a warning or ignore it in Eclipse you can still compile and use your program, but you ought to consider writing your own library that provides the same functionality or looking for a 3rd party lib. Otherwise, a JRE update could break your program.
You mention that you have already tried disabling this warning, and it had no effect -- did you perform a clean build afterwards? Try Project->Clean...
and see if you still get that error.
Upvotes: 0