Generics
Closed this issue · 10 comments
The following method signature exists in CommPortIdentifier.
public static Enumeration getPortIdentifiers()
It seems this should return
public static Enumeration<CommPortIdentifier> getPortIdentifiers()
I have examined the source code, and the returned object is built around a List<CommPortIdentifier> and an Iterator<CommPortIdentifier> (that is retrieved from the list.
It doesn't make any sense for the return values of this function to ever be anything other than Enumeration<CommPortIdentifier>.
Making this change will not affect binary compatibility. The Enumeration interface was itself updated to Enumeration<T> in Java 1.5.
The latest version of PJC (1.0) requires Java 1.5 anyway, so no new program must support generics anyway.
I haven't studied the code to see if there are other places where raw types are used in the interface. This is the only one that affected my code.
Thanks, but if it affects source compatibility then this is a no-go as the stated aim of PJC is to be JavaComm and RXTX compatible.
What do you mean by “if it affects source compatibility” in this context?
If someone switched rom RxTx to PJC by swapping the source code what would break as a result of this change?
If someone switched from RxTx to PJC by doing nothing but swap the .jar libraries, what would break as a result of this change?
As long as the original project was already targeting 1.5 or higher this should be 100% compatible with RxTx and JavaComm.
What am I missing here?
—
derik
On May 17, 2016, at 1:33 AM, nyholku <notifications@github.commailto:notifications@github.com> wrote:
Thanks, but if it affects source compatibility then this is a no-go as the stated aim of PJC is to be JavaComm and RXTX compatible.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/86#issuecomment-219653728
I don't know if you are missing anything. I did not check (yet) what happens.
But the original spec (JavaComm) did not have Generics, basically we are would be changing the API by introducing them. If you change from JavaComm to PureJavaComm, with generics do you need to change anything but the import, that is the acid test.
Yes, we would be changing the API of PureJavaComm in exactly the same way that the API for Enumeration changed in Java 1.5. Due to the "controversial" way that Generics were implemented in Java 1.5, runtime code can't tell if you used generics or not. This allows legacy code using the raw Enumeration interface to work perfectly with Enumeration found in version 1.5 of the JDK. This is fortunate; all code using the raw Enumeration class, e.g. PJC, would not compile otherwise. In a similar manner, if PJC is updated to use generics, existing client code still using the raw type are guaranteed to work.
I believe that if Sun had still been maintaining it, they would have updated the JavaComm interface in just like they updated Enumeration.
The advantage to changing the interface to use generics, aside from the obvious one of not using raw types where the modern interface specifies a generic, is type safety.
What happened to/with Java 1.5 and Generics makes little difference here.
The question is weather old code compiles without mods or not. And also backwards, if you write code using PJC can you then use it with RXTX or JavaComm without mods. The package name notwithstanding. If the answer is yes, then I'm for this change. If the answer is not, then this is out.
Every now and then this project attracts people who want to modernise it, add iterators and what not. All perfectly sensible things but they go against the stated goal of this project. And I believe most people using this library are more concerned weather the works as it should that weather it CommPortIdentifier support modern iterators or Generics.
I would suggest that those people start a new project on top of PJC that implements a better and more modern API leveraging the years of debugging that PJC offers. I might even consider adding that API to the PJC project into a sub package of purejavacomm package.
We are talking at cross purposes. Let me start again.
You said
If you change from JavaComm to PureJavaComm, with generics do you need to change anything but the import, that is the acid test.
My change passes that test. My example of how Sun upgraded the JDK to use generics in Java 1.5 without breaking backwards compatibility failed to assure you that this change was so. Is there anything more that I can say or do validate my claim?
And also backwards, if you write code using PJC can you then use it with RXTX or JavaComm without mods.
My change passes that test too. Suppose I write client code like the following for use with PJC.
Enumeration<CommPortIdentifier> ports = CommPortIdentifier.getPortIdentifiers();
I will receive a warning if I compile that code against a library that implements JavaComm, which uses raw types. The raw return type in the old API allows implementors of the interface put something other than a CommPortIdentifier in that Enumeration. This violates the contract of the function of course, but the compiler can't verify this so you get a warning.
The warning I receive from the compiler will not prevent compilation! And the resulting byte code will only fail at runtime if the library violates the contract. But if the library does violate the contract, then your code would have failed even if you had used raw types for everything.
Right, so if it compiles each way I'm fine with this.
I've made the change and pushed it to github but not yet released it as there is Windows bug fix pending test.
Acknowledged.
Thanks.
On May 21, 2016, at 9:32 PM, nyholku <notifications@github.commailto:notifications@github.com> wrote:
I've made the change and pushed it to github but not yet released it as there is Windows bug fix pending test.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHubhttps://github.com//issues/86#issuecomment-220813804
This has now been released