Bug 38531 - IllegalArgumentException "Source attachment path should be absolute"
Summary: IllegalArgumentException "Source attachment path should be absolute"
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.0 M2   Edit
Assignee: Philipe Mulet CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 38540 38572 39075 39125 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-06-05 12:21 EDT by Rafael Chaves CLA
Modified: 2003-08-06 12:51 EDT (History)
5 users (show)

See Also:

Attachments
log file (302.07 KB, text/plain)
2003-06-05 12:23 EDT, Rafael Chaves CLA 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rafael Chaves CLA 2003-06-05 12:21:48 EDT 
build i20030604

Maybe it was just for debugging purposes, but in the first (and only in the
first) time I run this build with an existing workspace, I got dozens of stack
traces like below (will attach log). Eclipse seemed to be working properly.

!ENTRY org.eclipse.jdt.core 4 4 Jun 05, 2003 11:59:16.702
!MESSAGE Source attachment path should be absolute: ""
!STACK 0
java.lang.IllegalArgumentException
	at java.lang.Throwable.<init>(Throwable.java)
	at org.eclipse.jdt.core.JavaCore.newLibraryEntry(JavaCore.java:2362)
	at org.eclipse.jdt.core.JavaCore.getResolvedClasspathEntry(JavaCore.java:1804)
	at
org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1533)
	at
org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1476)
	at
org.eclipse.jdt.internal.core.JavaProject.getResolvedClasspath(JavaProject.java:1452)
	at org.eclipse.jdt.core.JavaCore.updateVariableValues(JavaCore.java:3251)
	at org.eclipse.jdt.core.JavaCore.setClasspathVariables(JavaCore.java:3053)
	at org.eclipse.jdt.core.JavaCore.setClasspathVariable(JavaCore.java:3025)
	at
org.eclipse.jdt.internal.launching.JavaClasspathVariablesInitializer.setJREVariable(JavaClasspathVariablesInitializer.java:102)
	at
org.eclipse.jdt.internal.launching.JavaClasspathVariablesInitializer.initialize(JavaClasspathVariablesInitializer.java:79)
Comment 1 Rafael Chaves CLA 2003-06-05 12:23:26 EDT 
Created attachment 5077 [details]
log file

Log contains all stack traces between the first and second time I ran Eclipse
on an existing workspace.
Comment 2 Philipe Mulet CLA 2003-06-05 12:27:34 EDT 
This is a warning printed by JDT/Core when one API is incorrectly used. It 
silently fixes up the argument and proceed, but this is flagging the offending 
usage.

This one is JDT/Debug/
Comment 3 Darin Swanson CLA 2003-06-05 12:49:27 EDT 
I believe that I missed an update in the source root path in 
VMDefinitionsContainer#getLibraryLocation(Element) to conform to enforcement of 
the API in JDT Core.
Comment 4 Darin Swanson CLA 2003-06-05 13:54:58 EDT 
Fixed in VMDefinitionsContainer.
Please verify Luc.
Comment 5 Luc Bourlier CLA 2003-06-05 14:12:41 EDT 
Verified.
Comment 6 Darin Swanson CLA 2003-06-05 16:11:25 EDT 
*** Bug 38540 has been marked as a duplicate of this bug. ***
Comment 7 Darin Wright CLA 2003-06-12 15:57:59 EDT 
This fix seems to have caused a breakage in source lookup.
Comment 8 Darin Wright CLA 2003-06-12 16:38:32 EDT 
Philippe, there is trouble here...

We are trying to set a classpath variable (JRE_SRC) to Path.EMPTY. This in turn 
seems to cause the java model to create a library entry with an EMPTY source 
attachment (rather than "null"). However, since we are not allowed to set a 
classpath variable to "null", we have no way to distinguish between a ROOT path 
and an EMPTY path. 

We either need to be able to set a classpath variable to null, or be allowed to 
use an EMPTY path as a source attachment path.
Comment 9 Philipe Mulet CLA 2003-06-13 10:46:19 EDT 
Setting a classpath variable to null isn't an option since it is used to denote 
variable deletion.

However assigning source attachment to an empty path is tolerable.
Will be in next integration build.

Can I consider then removing the logging, and simply throwing an exception in 
other cases where a relative source attachment would be used ?
Comment 10 Darin Wright CLA 2003-06-13 10:57:41 EDT 
Yes, we agree that we should be able to set a claspath variable to Path.EMPTY, 
and that a classpath entry source attachment path can be set to "" (empty 
String), which is equivalent to "null".
Comment 11 Philipe Mulet CLA 2003-06-13 11:09:13 EDT 
Done deal.

Fixed. Will keep logging behavior until 3.0M2, and then will throw exception.
Comment 12 Philipe Mulet CLA 2003-06-13 11:09:34 EDT 
Fixed
Comment 13 Philipe Mulet CLA 2003-06-19 17:51:26 EDT 
*** Bug 39075 has been marked as a duplicate of this bug. ***
Comment 14 Philipe Mulet CLA 2003-06-19 17:54:24 EDT 
*** Bug 39125 has been marked as a duplicate of this bug. ***
Comment 15 David Audel CLA 2003-07-16 09:39:51 EDT 
Verified.
Comment 16 Darin Wright CLA 2003-08-06 12:51:18 EDT 
*** Bug 38572 has been marked as a duplicate of this bug. ***