[jdt-apt-dev] RE: [jdt-core-dev] CAUTION: IClassFile.getType() will no l

["Walter Harley" <wharley@xxxxxxx>]

Thanks for the warning, Frederic.

If you release the change on Friday after the N20070302-0010 build has started, then I can update jdt.apt.core in time for the Saturday build.

Or if you would prefer, you can just commit the change yourself.  (The code should function correctly without the catch block; it is not assuming anything about the model being populated, as far as I can tell.)  Here's the patch to apply:



### Eclipse Workspace Patch 1.0
#P org.eclipse.jdt.apt.core
Index: src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java
===================================================================
RCS file: /cvsroot/eclipse/org.eclipse.jdt.apt.core/src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java,v
retrieving revision 1.29
diff -u -r1.29 BaseProcessorEnv.java
--- src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java	10 Feb 2007 02:32:39 -0000	1.29
+++ src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java	28 Feb 2007 16:20:54 -0000
@@ -581,10 +581,7 @@
 			catch (JavaModelException e) {}
 		}
 		else if (classFile != null) {
-			try {
-				type = classFile.getType();
-			}
-			catch (JavaModelException e) {}
+			type = classFile.getType();
 		}
 
 		// Given a type, we can construct a package declaration impl from it,
 









-----Original Message-----
From: jdt-core-dev-bounces@xxxxxxxxxxx [mailto:jdt-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Frederic Fusier
Sent: Wednesday, February 28, 2007 7:47 AM
To: jdt-dev@xxxxxxxxxxx; jdt-core-dev@xxxxxxxxxxx; jdt-ui-dev@xxxxxxxxxxx; jdt-apt-dev@xxxxxxxxxxx; jdt-debug-dev@xxxxxxxxxxx
Subject: [jdt-core-dev] CAUTION: IClassFile.getType() will no longer throwJavaModelException


There is currently an inconsistency on IClassFile#getType() method which throws a JavaModelException although its implementation does not (see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=154667).

This is also confusing for clients who may think that calling this method will populate the model although it does not (this is a handle-only method).

** We definitely want to fix this problem in next week integration build **

Note that, if this change has no impact on binary compatibility, it breaks source compatibility! Clients of this API must remove unnecessary catch block in their code as it will become invalid and be flagged as error by the compiler.

**********************************************************************
**** We plan to release this change in JDT/Core HEAD next Friday *****
**********************************************************************

Here are the 'Unreachable catch block' compiler errors got after having applied the patch in an Eclipse full source workspace using I20070227-0800
build:

plugin org.eclipse.jdt.apt.core
===============================
 - /src/org/eclipse/jdt/apt/core/internal/env
      BaseProcessorEnv.java: line 587

plugin org.eclipse.jdt.debug.ui
===============================
 - /src/org/eclipse/jdt/internal/debug/ui
      TypeNameResolver.java: line 59

plugin org.eclipse.jdt.ui
=========================
 - /src/org/eclipse/jdt/internal/corext/refactoring/rename
      GenericRefactoringHandleTransplanter.java: line 122
 - /src/org/eclipse/jdt/internal/ui/browsing
      MembersView.java: line 264
 - /src/org/eclipse/jdt/internal/ui/browsing
      TypesView.java: line 135
 - /src/org/eclipse/jdt/internal/ui/infoviews
      JavadocView.java: line 505
 - /src/org/eclipse/jdt/internal/ui/javaeditor
      InternalClassFileEditorInput.java: line 83
 - /src/org/eclipse/jdt/internal/ui/javaeditor
      JavaOutlinePage.java: line 973
 - /src/org/eclipse/jdt/internal/ui/text
      JavaOutlineInformationControl.java: line 789
 - /src/org/eclipse/jdt/internal/ui/typehierarchy
      TypeHierarchyLifeCycle.java: line 239
 - /src/org/eclipse/jdt/internal/ui/typehierarchy
      TypeHierarchyViewPart.java: line 1608
 - /src/org/eclipse/jdt/ui/actions
      FindAction.java: line 201

JDT/APT, JDT/UI and JDT/Debug please confirm by answering to this post that you will be able to release corresponding change in HEAD on Friday and avoid a failure in Saturday nightly build, thanks

Note that there are other references to this method in the workspace but they won't be broken by this change as they do no catch the exception (declaring method already throws the JME) or there's a call to another method which also throws the JME in the same try block...

I will also add an entry in 3.3 migration guide to document this change for other potential clients of this API.

Cordialement/Regards,

Frédéric


_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.