I know that an API is not supposed to be broken, but.... in real life this happens.
In the context of the API tooling effort, we need to handle this case when checking for binary compatibility between two Eclipse drops.
An example would be that an API provider defines an interface that can be implemented by clients with a method that takes an internal type as a parameter. This API is not usable for the clients. The provider then changes the signature of the method to use an interface type instead of the internal type. Now the API is usable, but this change technically speaking a breaking API change.
This kind of changes should be documented in the porting guide, but I believe it should also be document at the source code level.
One way to do this would be to have a javadoc tag on the corresponding API that would state this is a known breakage. Something like:
@breakage-change The parameter type has been changed to use an API type instead of an internal type
The binary compatibility checker could then realize that this is a known breakage and don't report it anymore.
The next question is: "Since this is an API breakage, should the version of the corresponding bundle change its major version?".
I'd like to get your opinions on this topic.
Thank you.
Wednesday, November 21, 2007
Monday, September 10, 2007
The method getCanonicalName() is undefined for the type Class
This is my first blog entry. So forgive me for my "poor" writing skills.
Last week compile errors were found in the nightly builds. The first error was:
The method getCanonicalName() is undefined for the type Class
This is actually quite simple to prevent this kind of errors. But before I talk about how to fix it, it should be clear to understand how this is possible.
This method is a method that is defined in 1.5. In Eclipse it would be tagged with the javadoc tag @since 1.5.
In order to get it, you need to start Eclipse with a JDK1.5 and never add another JRE in the installed JREs list. Then even if you specify that your project takes an execution environment 1.4, you will have a JRE 1.5 on the classpath. The JRE 1.5 that you used to start Eclipse has been installed by default. It is a potential match for an execution environment 1.4 and since there is no other JRE installed, it is used as the JRE library on the project classpath.
The Eclipse compiler doesn't check if a method is defined in the JRE1.5 or 1.4 even if the project settings are compliance 1.4, target 1.2 and source 1.3. We have requests to add this kind of support in the compiler, but this is not the purpose of this blog. So since the compiler doesn't check that the method that is used in the project comes from a 1.4 JRE, the project compiles fine on the committer's machine. Then the code is committed and retrieved for the next nightly build.
The nightly build is however using a JRE 1.4 on the project's classpath to match the 1.4 execution environment requirement. And this is how a compile error is raised during the nightly build. It might seem obvious and simple enough so that readers are wondering why I talk about this.
Last week the problem arised twice. Once for the error mentioned above and the second time with this error:
The method valueOf(String) in the type Long is not applicable for the arguments (long)
So it seems that it might be worthwhile to explain how to prevent it this error once for all. The solution is quite simple.
Always install the JRE that corresponds to the project's execution context requirement. And if your project doesn't have such a requirement, edit the manifest file to add it.
If a 1.4 JRE is installed when the execution environment 1.4 is specified for a project, it will be used. If you want to be sure which one is used, check the preference page Window>Preferences>Java>Installed JREs>Execution Environments.
Then you check which JRE is set to be a perfect match for the execution environment you are using.
Once this is done, you are sure that the right JRE ends up in the project's classpath and that if you code compiles in your workspace, it will also compile in the Eclipse builds.
Let me know if you find this kind of blog useful or completely obvious and useless.
Olivier
Last week compile errors were found in the nightly builds. The first error was:
The method getCanonicalName() is undefined for the type Class
This is actually quite simple to prevent this kind of errors. But before I talk about how to fix it, it should be clear to understand how this is possible.
This method is a method that is defined in 1.5. In Eclipse it would be tagged with the javadoc tag @since 1.5.
In order to get it, you need to start Eclipse with a JDK1.5 and never add another JRE in the installed JREs list. Then even if you specify that your project takes an execution environment 1.4, you will have a JRE 1.5 on the classpath. The JRE 1.5 that you used to start Eclipse has been installed by default. It is a potential match for an execution environment 1.4 and since there is no other JRE installed, it is used as the JRE library on the project classpath.
The Eclipse compiler doesn't check if a method is defined in the JRE1.5 or 1.4 even if the project settings are compliance 1.4, target 1.2 and source 1.3. We have requests to add this kind of support in the compiler, but this is not the purpose of this blog. So since the compiler doesn't check that the method that is used in the project comes from a 1.4 JRE, the project compiles fine on the committer's machine. Then the code is committed and retrieved for the next nightly build.
The nightly build is however using a JRE 1.4 on the project's classpath to match the 1.4 execution environment requirement. And this is how a compile error is raised during the nightly build. It might seem obvious and simple enough so that readers are wondering why I talk about this.
Last week the problem arised twice. Once for the error mentioned above and the second time with this error:
The method valueOf(String) in the type Long is not applicable for the arguments (long)
So it seems that it might be worthwhile to explain how to prevent it this error once for all. The solution is quite simple.
Always install the JRE that corresponds to the project's execution context requirement. And if your project doesn't have such a requirement, edit the manifest file to add it.
If a 1.4 JRE is installed when the execution environment 1.4 is specified for a project, it will be used. If you want to be sure which one is used, check the preference page Window>Preferences>Java>Installed JREs>Execution Environments.
Then you check which JRE is set to be a perfect match for the execution environment you are using.
Once this is done, you are sure that the right JRE ends up in the project's classpath and that if you code compiles in your workspace, it will also compile in the Eclipse builds.
Let me know if you find this kind of blog useful or completely obvious and useless.
Olivier
Subscribe to:
Posts (Atom)