INDEX.LIST file gives sun.misc.InvalidJarIndexException: Invalid index

[michael]

Building in Eclipse offline or online:

opening Python window -> sun.misc.InvalidJarIndexException: sun.misc.InvalidJarIndexException: Invalid in
dex

Running this at the command line fixes it (Java 7)

jar -i geogebra.jar geogebra_main.jar geogebra_gui.jar geogebra_cas.jar geogebra_algos.jar geogebra_export.jar geogebra_javascript.jar geogebra_properties.jar geogebra_usb.jar jlatexmath.jar jlm_cyrillic.jar jlm_greek.jar jython.jar

and then resigning geogebra.jar

files attached.

Possible solution: use Java 6/7 version of "jar -i"

	<!-- create index.list in geogebra.jar for optimized loading of other jars by Java classloader -->
	<target name="ggb-jar-index" depends="ggb-jar-files" description="create index in geogegebra.jar">
		<exec executable="jar" dir="${build.dir}">
			<arg value="i"/>
			<arg value="geogebra.jar"/>
			<arg value="geogebra_main.jar"/>
			<arg value="geogebra_gui.jar"/>
			<arg value="geogebra_cas.jar"/>
			<arg value="geogebra_algos.jar"/>
			<arg value="geogebra_export.jar"/>
			<arg value="geogebra_javascript.jar"/>
			<arg value="geogebra_properties.jar"/>
			<arg value="geogebra_usb.jar"/>
			<arg value="jlatexmath.jar"/>
			<arg value="jlm_cyrillic.jar"/>
			<arg value="jlm_greek.jar"/>
			<arg value="jython.jar"/>
		</exec>
	</target>

[michael]

I've written a little script ~/fixIndex42.sh which uses the default Java on the server (Java6u26) to run jar -i and resign so after this, the Python window works:

buildggb42.sh
fixIndex42.sh
deployggb42.sh

[zoltan]

Thanks, Mike, for the nice script. It's perfect, the only problem is that the same steps are done twice now. (First with jar version 5, then jar version 6.) It's just a performance issue, of course.

I suggest the following to substitute your script:

• Split the pack.xml targets "geogebra*-aftervanilla" to 1) clean..ggb-jar-files*..copyDebug*..signDebug..obfuscate*..(delete3D)..ggb-jar-index*..copyJars*, 2) sign-pack-finish.
• Modify step 6/4. in make-vanilla-jars to run these 2 steps (instead of the current one), but the first one to run with Java 6. (Only the sign and the pack targets require Java 5.)

If you agree, I'll do the changes for this.

[michael]

Sounds perfect, thanks :)

[zoltan]

My idea will not work: the pack utility for Java 5 seems to break the .jar archive. (We use Java 5 for packing since to prevent http://www.geogebra.org/forum/viewtopic.php?f=8&t=3972&st=0&sk=t&sd=a&start=15.)

I'm checking what happens if the whole packing process is done with Java 6 (or 7?).

[michael]

perhaps we should put a dummy class file in geogebra_properties.jar and use Java 6 (7?) for everything?

[zoltan]

Life is uneasy.

I tried pure Java 6 compilation - it succeeds: no dummy class is needed in geogebra_properties.jar! But tough luck: the signed unpacked JARs have the index file problem this way, too.

I tried to understand your fixing script thorougly today, but I'm not finished with it yet. First of all, you run jarsigner twice for signed unpacked and unsigned unpacked, and once for debug. AFAIK the official way is to use jarsigner only once for signed unpacked, and never for unsigned unpacked. For the unsigned unpacked set you run both a repack and a gzip process - here repack shouldn't be run IMHO. (See the diagram at http://www.geogebra.org/trac/wiki/BuildingProcess#Packaging for details.)

Have you found any help in the internet when you created your fixing script? Or you just tried to do your best? This is very important since I removed a jarsigner+repack step 5 months ago from the whole building process - that time I understood that we must follow the official packaging methods literally. When I removed the extra steps, the SHA1 checksums became fixed automatically!

Could you please give some tips why is this index error occuring? Thanks! ;-)

[michael]

I just played around until the index file worked with View -> Python Window

At the moment in the build, does the "jar -i" happen before or after the repack? maybe it needs to happen after.

With "Java 6 compilation - it succeeds" don't forget we need Java 5 class files, and also we must run this in Java 5 at the end:

jarsigner -verify unpacked.jar

[zoltan]

Replying to michael:

At the moment in the build, does the "jar -i" happen before or after the repack? maybe it needs to happen after.

For signed JARs, currently:

... -> proguard -> index -> repack -> sign -> pack (gzip)

Shall I try

... -> proguard -> repack -> index -> sign -> pack (gzip)

instead?

With "Java 6 compilation - it succeeds" don't forget we need Java 5 class files, and also we must run this in Java 5 at the end:

jarsigner -verify unpacked.jar

Are you sure we need the Java 5 version here?

[zoltan]

No luck on changing the order:

jarsigner: java.lang.SecurityException: SHA1 digest error for geogebra/AppletImplementationInterface.class

[michael]

Shall I try

... -> proguard -> repack -> index -> sign -> pack (gzip)

instead?

Worth a try - it might explain the problem if the order of files in the index is important. Another idea: pack200 jython.jar before starting (probably not a good solution as the problem might then come back if we upgrade it, but might be a good experiment)

With "Java 6 compilation - it succeeds" don't forget we need Java 5 class files, and also we must run this in Java 5 at the end:

jarsigner -verify unpacked.jar

Are you sure we need the Java 5 version here?

Actually Java 6 is probably OK. Perhaps we should check it with 5 though?

[zoltan]

It seems changing the order can indeed do some fixing. Now I have a different error message:

2012.01.10. 12:35:51  
STDERR: Exception in thread "AWT-EventQueue-0" 
2012.01.10. 12:35:51  
STDERR: Traceback (most recent call last):
  File "__pyclasspath__/geogebra/plugin/jython/pyggb.py", line 61, in init

2012.01.10. 12:35:51  
STDERR: AttributeError: 'geogebra.g.n' object has no attribute 'getGgbApi'

Do you think this is another type of error? (I haven't committed my change with the order change yet.)

[zoltan]

'geogebra.g.n': this is main/Application.class - only problematic when I open the Python window in the signed unpacked set.

[zoltan]

The unsigned unpacked set also has this problem! (debug is not affected, maybe a proguard problem?)

[arnaud]

Replying to zoltan:

STDERR: AttributeError: 'geogebra.g.n' object has no attribute 'getGgbApi'

Do you think this is another type of error? (I haven't committed my change with the order change yet.)

I know Mike added a call to Application.getGgbApi in pyggb.py yesterday. The name probably still gets obfuscated by proguard. One solution would be to add

    public GgbAPI getGgbApi() {
        return app.getGgbApi()
    }

To the PythonAPI class, and change

    ggbapi = app.getGgbApi()

to

    ggbapi = api.getGgbApi()

in pyggb.py (can't do this from work).

Arnaud

[michael]

Replying to zoltan:

It seems changing the order can indeed do some fixing. Now I have a different error message:

2012.01.10. 12:35:51  
STDERR: Exception in thread "AWT-EventQueue-0" 
2012.01.10. 12:35:51  
STDERR: Traceback (most recent call last):
  File "__pyclasspath__/geogebra/plugin/jython/pyggb.py", line 61, in init

2012.01.10. 12:35:51  
STDERR: AttributeError: 'geogebra.g.n' object has no attribute 'getGgbApi'

As Arnuad says, this is a minor and unrelated error. Zoltan, please commit your change, then I can do a new release when the other problem is fixed

[zoltan]

Fixed in [14852] and [14854]. (The original problem was fixed in [14828].)