Bug 94163 - more than one native library per JAR?
Summary: more than one native library per JAR?
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.1 M7   Edit
Assignee: Kevin Barnes CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-09 13:07 EDT by Martin Aeschlimann CLA
Modified: 2005-05-12 15:01 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Aeschlimann CLA 2005-05-09 13:07:37 EDT
20050509

I assume a request that we soon wil get is to be able to add more than one
native library to a classpath entry.
Comment 1 Darin Wright CLA 2005-05-10 12:06:45 EDT
The current API for JavaRuntime.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY supports 
multiple libraries per archive by allowing for more than one attribute with 
the same key.

We believe we should change the API such that we do not use more than one 
attribute with the same key. JDT does not currerntly verify this restriction, 
but may want to. Thus, the API spec for CLASSPATH_ATTR_LIBRARY_PATH_ENTRY 
would need to be changed to this:

/**
 * Attribute key for a classpath attribute containing to a comma separated
 * list of shared libraries that should appear on the
 * <code>-Djava.library.path</code> system property.
 * <p>
 * The value is a list of comma separated strings representing paths. Each
 * string is used to create an <code>IPath</code> using the constructor
 * <code>Path(String)</code>. A string used to construct a path may contain
 * <code>IStringVariable</code>'s. Variable substitution is performed on each
 * string before a path is constructed from a string.  
 * </p>
 * <p>
 * If the resulting <code>IPath</code> is a relative path, it is interpretted
 * as relative to the workspace location. If the path is absolute, it is 
 * interpretted as an absolute path in the local file system.
 * </p>
 * @since 3.1
 * @see org.eclipse.jdt.core.IClasspathAttribute
 */
Comment 2 Martin Aeschlimann CLA 2005-05-10 12:20:42 EDT
Comma might not be a good separator as it can occurr in names.
'\0' might be a suggestion, but we would have to see how jdt.core handles that.

Comment 3 Martin Aeschlimann CLA 2005-05-10 12:26:38 EDT
I filed bug 94404 for the specification update in JDT core.
Comment 4 Darin Wright CLA 2005-05-11 16:19:49 EDT
Marking as M7 candidate.
Comment 5 Darin Wright CLA 2005-05-11 21:19:23 EDT
Jim, we'd like to make this change for M7. It is an API change, but it is new 
3.1 API as of 3.1M6, and JUI is the only known consumer of the API (as well as 
jdt.launching). Please see comment#1 for a description of the change. If you 
have a good suggestion for the user of a separator for file system paths, 
please advise.
Comment 6 Jim des Rivieres CLA 2005-05-11 21:40:56 EDT
approved for M7.

I do not have any good suggestions for file system path separators.

Comment 7 Darin Wright CLA 2005-05-12 12:44:39 EDT
Fixed.

Modified spec for CLASSPATH_ATTR_LIBRARY_PATH_ENTRY and added two methods to 
JavaRuntime to encode/decode the attribute's value to/from strings. Updated 
tests as well. See #newLibraryPathsAttribute(String[]) and #getLibraryPaths().

The JUI needs to catch upto this change. There are no compliation errors, but 
the feature won't work until the proper encoding of the attribute is used.
Comment 8 Darin Wright CLA 2005-05-12 12:45:03 EDT
Please verify, Kevin.
Comment 9 Darin Wright CLA 2005-05-12 13:08:50 EDT
Re-opening to consider using "|" as separator.
Comment 10 Darin Wright CLA 2005-05-12 13:24:28 EDT
Fixed, using "|" as separator. This means the current JUI still works (but 
needs to be enhanced to add multipe paths). Please verify, Kevin. (Changes to 
JavaRuntime).
Comment 11 Kevin Barnes CLA 2005-05-12 15:01:46 EDT
verified