B4J Question ArchiverPLUSzip will it work? (originally for B4A)

[aidymp]

Hi, I was hoping ArchiverPLUSzip.lib (a Chargeable lib from Informatix) would work in B4J, as the original Archiver.lib is flawed, but after adding the lib and just this code..

Sub Process_Globals
  Private Arc As  ArchiverPlusZip
  ...

I get this error

Program started.
main._process_globals (java line: 316)
java.lang.VerifyError: Expecting a stackmap frame at branch target 104
Exception Details:
Location:
b4a/flm/archiverplus/ArchiverPlusZip.a(Lanywheresoftware/b4a/BA;La/a/a/a/c;Ljava/lang/StringV @20: ifle
Reason:
Expected stackmap frame at this location.
Bytecode:
0x0000000: 2c04 b500 632a 2cb4 0062 b500 8f2d b600
0x0000010: deb6 00d9 9e00 542a b400 8f2b b500 852a
0x0000020: b400 8fbb 005a 592d b600 deb2 008c b600
0x0000030: ddb8 00df b700 e012 1bb6 00e2 b600 e3b5
0x0000040: 0086 2ab4 008f bb00 5a59 2db6 00de b200
0x0000050: 8cb6 00dd b800 dfb7 00e0 121c b600 e2b6
0x0000060: 00e3 b500 87a7 001b 2ab4 008f 01b5 0085
0x0000070: 2ab4 008f 01b5 0086 2ab4 008f 01b5 0087
0x0000080: 2ab4 008f 03b5 0088 b1
at b4j.example.main._process_globals(main.java:316)
at b4j.example.main.initializeProcessGlobals(main.java:238)
at b4j.example.main.start(main.java:33)
at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$163(LauncherImpl.java:863)
at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$176(PlatformImpl.java:326)
at com.sun.javafx.application.PlatformImpl.lambda$null$174(PlatformImpl.java:295)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.javafx.application.PlatformImpl.lambda$runLater$175(PlatformImpl.java:294)
at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at com.sun.glass.ui.win.WinApplication.lambda$null$149(WinApplication.java:191)
at java.lang.Thread.run(Thread.java:745)

I have spoken to Informatix who said "
You should ask Erel because I have no knowledge of B4J. It seems there's a problem with the thread run in the background. ArchiverPlusZip does not call the Android API so it should work with B4J."

Thanks

Aidy

 

[Erel]

I don't think that it is related to a threading issue. It seems like it calls a missing API.

BTW, which problem did you encounter with the Archiver library?

 

[aidymp]

I don't think that it is related to a threading issue. It seems like it calls a missing API.

BTW, which problem did you encounter with the Archiver library?

The Original Archiver lib cant seem to handle some characters in filenames eg (Pathé), or maybe the depth of the path. So a zip that was created with winrar, in some cases will not extract, i just quits when it gets to the offending file, Windows default zip program the one bundled with windows also has this problem, I found the other day when tying to zip one of these folders, it displays an error saying that some files cannot be zipped, and need removing! before it even starts the process.

I have seen on the internet that it seems to be a common problem in archives using java , But ArchiverPLUSzip.lib works great on Android.

The problem I have is that the zips are not mine, and most DO contain the foreign characters and most are zipped with winrar or similar! I paid for the lib because on Android it solved everything above! and I am more than happy with the lib, but I really could do with something similar for B4J.

I am thinking, I may shell 7zip, for now, and hope I can get some output I can display.

Thanks

Aidy

 

[Informatix]

I don't think that it is related to a threading issue. It seems like it calls a missing API.

The Java code calls only the B4A libraries that follows:
- anywheresoftware.b4a.BA;
- anywheresoftware.b4a.keywords.Common;
- anywheresoftware.b4a.objects.collections.List;
and a few standard Java libraries (java.io.File, java.io.IOException, etc.). It is optimized for Java 7.

 

[Erel]

Maybe the library obfuscation broke it. This is not a "normal" Java error.

 

[Informatix]

Is Java 7 used?
This case is documented at length on internet. The solution is either to run the right version of Java or to launch the JVM with -XX:-UseSplitVerifier.

 

[Erel]

Java 8 is required for UI apps.

 

[Informatix]

Java 8 is required for UI apps.

"-XX:-UseSplitVerifier" is not possible with Java 8, so we're stuck. This is not related to obfuscation but to the lack of stack map frame which is required by Java 8. We have to suggest to Oracle to stop breaking things by adding this kind of useless bullshit to Java.
Is there a strong reason to prefer Java 8 over Java 7?

 

[Erel]

It is most probably related to proguard: http://stackoverflow.com/questions/...causes-verifyerror-expecting-a-stackmap-frame

Is there a strong reason to prefer Java 8 over Java 7?

Yes. There were many improvements in JavaFX.

 

[Informatix]

It is most probably related to proguard: http://stackoverflow.com/questions/...causes-verifyerror-expecting-a-stackmap-frame

Yes I know. The subject of the SO thread is wrong; it's not related to obfuscation as explained by the ProGuard's author. ProGuard does not update the stack map table when processing the classes, which is useless for Android and for 99.99% of Java developpers and slows down apps. Unfortunately, Oracle made this mandatory with Java 8 and I have no solution right now (the solution provided in the thread does not seem to work). As my target is only Android, I won't spend time on that issue.

 

[aidymp]

OK so its not going to work for B4J then, thanks for looking guys, im still happy with the lib, working with B4J would have just been a lucky plus.

Thanks

Aidy