guiyu / android-apktool

Automatically exported from code.google.com/p/android-apktool
Other
1 stars 0 forks source link

remove jre7 code #527

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Drop us back to JRE6 compatible. Rewrite any Java7 code.

Original issue reported on code.google.com by connor.tumbleson on 14 Oct 2013 at 2:11

GoogleCodeExporter commented 9 years ago
where can I download 2.0 compiled version?

Original comment by pangqing...@gmail.com on 14 Oct 2013 at 2:05

GoogleCodeExporter commented 9 years ago
Issue 547 has been merged into this issue.

Original comment by connor.tumbleson on 12 Nov 2013 at 12:49

GoogleCodeExporter commented 9 years ago
Issue 559 has been merged into this issue.

Original comment by connor.tumbleson on 3 Dec 2013 at 12:09

GoogleCodeExporter commented 9 years ago
Applying following patch file fixes the problem.

diff --git a/brut.apktool/apktool-lib/src/main/java/brut/androlib/Androlib.java 
b/brut.apktool/apktool-lib/src/main/java/brut/androlib/Androlib.java
index b969824..5460bae 100644
--- a/brut.apktool/apktool-lib/src/main/java/brut/androlib/Androlib.java
+++ b/brut.apktool/apktool-lib/src/main/java/brut/androlib/Androlib.java
@@ -585,7 +585,7 @@ public class Androlib {

             // in order to get the path relative to the zip, we strip off the absolute path, minus what we
             // already have in the zip. thus /var/files/apktool/apk/unknown/folder/file => /folder/file
-            Path dest = fs.getPath(root.toString() + 
insert.getAbsolutePath().replace(location.toString(),""));
+            Path dest = fs.getPath(root.toString(), 
insert.getAbsolutePath().replace(location.toString(),""));
             Path newFile = Paths.get(insert.getAbsolutePath());
             Files.copy(newFile,dest, StandardCopyOption.REPLACE_EXISTING);
             fs.close();
@@ -598,7 +598,7 @@ public class Androlib {
         try(FileSystem fs = FileSystems.newFileSystem(apkFileSystem, zip_properties)) {

             Path root = fs.getPath("/");
-            Path dest = fs.getPath(root.toString() + 
insert.getAbsolutePath().replace(location.toString(),""));
+            Path dest = fs.getPath(root.toString(), 
insert.getAbsolutePath().replace(location.toString(),""));
             Path parent = dest.normalize();

             // check for folder existing in apkFileSystem

Original comment by funorp...@gmail.com on 5 Dec 2013 at 8:12

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for that fix, I'll test it tonight on Windows (which is where I was 
experiencing the problems)

Original comment by connor.tumbleson on 5 Dec 2013 at 1:30

GoogleCodeExporter commented 9 years ago
Confirmed working under same conditions as Issue 559. Thanks for the patch!

Original comment by aferna...@gmail.com on 7 Dec 2013 at 3:13

GoogleCodeExporter commented 9 years ago
Issue 582 has been merged into this issue.

Original comment by connor.tumbleson on 4 Jan 2014 at 12:06

GoogleCodeExporter commented 9 years ago
Issue 583 has been merged into this issue.

Original comment by connor.tumbleson on 6 Jan 2014 at 6:08

GoogleCodeExporter commented 9 years ago
Issue 587 has been merged into this issue.

Original comment by connor.tumbleson on 9 Jan 2014 at 2:02

GoogleCodeExporter commented 9 years ago
and hw to apply this patch?

Original comment by abdulla....@gmail.com on 9 Jan 2014 at 4:23

GoogleCodeExporter commented 9 years ago
Issue 587 has been merged into this issue.

Original comment by connor.tumbleson on 9 Jan 2014 at 4:40

GoogleCodeExporter commented 9 years ago
On second thought. I like Java7.

Release Dates
Java SE 6 (December 11, 2006)
Java SE 7 (July 28, 2011)
Hell, Java 8 betas are even out now.

Rewriting 3 major functions (Unknown Files, SmaliDebugging, Unit-Tests) into 
JRE6 will take a lot of time even further delaying the release of Apktool2.

Yes, there are errors like the above one, but that was due to me learning Jave 
NIO2 as I was programming it. It could use a JRE7 small rewrite to fix up the 
problems.

Then we should embrace JAVA7, if we choose to stay with it. Rewrite to use 
everything and anything that helps make our codebase more consistent. 

try-with-resources, diamond operators, multi-catches, etc. I'll sleep on it, 
but really favoring Java7.

Original comment by connor.tumbleson on 10 Jan 2014 at 4:35

GoogleCodeExporter commented 9 years ago
In case this is still under debate, I vote that you stay on Java 7.  Oracle 
stopped releasing Java 6 updates in February 2013.

Original comment by achen.c...@gmail.com on 19 Feb 2014 at 9:29

GoogleCodeExporter commented 9 years ago
 I vote for Java7 as well, I see no reason to use Java6 as it's really old and Java8 will be out soon.

Original comment by mfor...@gmail.com on 12 Mar 2014 at 4:04

GoogleCodeExporter commented 9 years ago
We are sticking with Java7. If you want to use Apktool on Android, you can do 
the needed developing yourself to strip the 1.7 stuff and remove other 
dependencies.

(We will still move SnakeYAML to an Android compatible version in time, to ease 
the process)

Java8 is out. Java7 has been for 2.5 years. Java6 is old.

Original comment by connor.tumbleson on 26 Mar 2014 at 11:47