Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 295428

Summary: Broken 1.3M3 target platform (ClassFormatError)
Product: [RT] RAP Reporter: Ivan Furnadjiev <ivan>
Component: RelengAssignee: Project Inbox <rap-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: batxut, manuel.woelker
Version: 1.3   
Target Milestone: 1.3 M4   
Hardware: All   
OS: All   
Whiteboard:

Description Ivan Furnadjiev CLA 2009-11-18 06:25:00 EST 
The target platform downloaded from this link:
http://www.eclipse.org/downloads/download.php?file=/rt/rap/1.3/rap-runtime-1.3.0-M3-20091110-1732.zip
is broken. At least the "org.eclipse.osgi_3.6.0.v20091023.jar" bundle differs (MD5) form the one in "org.eclipse.rap.ui.intro_1.3.0.20091110-1744.jar/target/target.zip".
As a result the OSGI framework wouldn't start and the following error appears in the log file:
Here's the stacktrace from the log file :

!SESSION Sat Nov 14 02:09:50 WIT 2009
------------------------------------------
!ENTRY org.eclipse.equinox.launcher 4 0 2009-11-14 02:09:50.572
!MESSAGE Exception launching the Eclipse Platform:
!STACK
java.lang.ClassFormatError: Illegal field name "
" in class org/eclipse/osgi/internal/profile/Profile
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoade r.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320 )
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 559)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514)
at org.eclipse.equinox.launcher.Main.run(Main.java:1311)
at org.eclipse.equinox.launcher.Main.main(Main.java:1287)
Installing the target platform from within the Eclipse -> Welcome -> Overview -> RAP -> Install Target Platform works.
Comment 1 Manuel Woelker CLA 2009-11-20 09:23:44 EST 
Another variant of the above mentioned workaround is to download the target platform contained in the intro bundle of the tooling and extract the osgi bundle from there.

http://download.eclipse.org/rt/rap/1.3/tooling/plugins/org.eclipse.rap.ui.intro_1.3.0.20091110-1744.jar

The osgi bundle itself is in the file target/target.zip within the jar.
Comment 2 Ralf Sternberg CLA 2009-11-24 17:13:34 EST 
The reason for the different md5 sums is that we used to push all bundles through the pack-200/signing process (so far, we only excluded icu and junit from this procedure). Obviously, the osgi bundle did not survive pack200 normalization this time and I only checked the runtime shipped with the tooling :(

Since the non-rap bundles in our target platform are signed already, there is no use in doing that again. This practice even leads to different variants of the same bundle in the same version, which I think must be considered broken.

I now excluded all non-rap bundles from pack200 and signing, so we ship the original bundles untouched. Uploaded a repaired zip file for M3, same version, same URL as above.
Comment 3 Rüdiger Herrmann CLA 2009-12-04 05:05:19 EST 
I consider this bug as fixed (see comment #2). Please re-open if someone disagrees.