Hi,
Streamsupport will be really helpful for those of us stuck on older VMs. A lot of older devices exist where a 1.4 JVM is the only option. Investigating using streamsupport with Retrotranslator http://retrotranslator.sourceforge.net in the same was as it currently uses the concurrency back-port might well give this project a grateful additional audience.
Thanks, Dan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Heaven forbid, that would be a bold venture! I understand your point of view - but I don't think a 1.4 backport would be possible (not at a satisfactory performance level and not as robust as a 1.5 backport might be).
Unfortunately, there is a bit more to it than simply moving default/static interface methods to companion classes and let retrolambda / Retrotranslator do the rest. The streams library (and JSR 166) has a strong dependency on several things:
the new Java memory model from JSR 133
explicit JVM support for the intrinsics in sun.misc.Unsafe
a lot of runtime API support (including things like private members in java.lang.Thread and so on)
Given these close ties to the platform I don't expect it to be practical on 1.4 with its broken Java memory model.
Streamsupport doesn't really use some "concurrency back-port", what it uses in some sense IS the Java 8 code, adapted to Java 6 to compensate for missing methods in sun.misc.Unsafe and things like implementation differences in java.lang.Thread.
What's more, for the streams library actually only 5 classes are needed (CountedCompleter, ForkJoinPool, ForkJoinTask, ForkJoinWorkerThread and ThreadLocalRandom) - all the rest is already there in Java 6. These 5 classes had to be reimplemented anyway - even if the target platform would have been Java 7.
All these things would be missing on 1.4. And I don't believe that I could make this working correctly with a JSR 166 backport library like http://backport-jsr166.sourceforge.net/
It was hard enough for Java 6, believe me. I'm not sure what a Java 5 backport would imply, but 1.4 - I'm sorry to say: no way.
Cheers,
Stefan
Last edit: Stefan Zobel 2014-07-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi again,
I'm not so aware of the intricacies, so greatly appreciate the thorough explanation. Perhaps you'd indulge some (more) dumb questions?
What is it that Java 6 provides that Java 5 doesn't that causes the minimum JRE selection for streamsupport? (You probably answered this already, but I was hoping to pick it out to aide my understanding). I've only encountered one thing on 1.5 that Retrotranslator wasn't able to provide, the AbstractQueuedSynchronizer - though their support for the 1.5 APIs isn't complete, it's pretty high!
Could it be advantageous to allow "retrotranslating" of JARs to allow developers to continue to use e.g. java.lang.function packages which are then substituted for the java8... packages during translation? Retrotranslator also supports embedding dependencies, both features I've found very useful at one time or another.
Thanks again for streamsupport, I'm looking forward to making much use of it!
Dan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) I'm not saying that it wouldn't work on Java 5. sun.misc.Unsafe and j.u.c.locks.LockSupport might be a problem if they don't have all the methods needed (maybe even java.lang.Thread - I don't know, it's been a long while since I last looked at the Java 5 sources).
The remaining delta for the runtime API migth well be replenished (btw, AbstractQueuedSynchronizer is available in Java 5). But note: even if there existed a Java 5 version of streamsupport, it wouldn't be feasible to translate it back to a working 1.4 Jar using RetroTranslator for the above mentioned reasons.
I mainly chose Java 6 as the "minimum" JRE because it
seemed reasonable
it's already 8 years old now (and has already passed "End of Life")
sure was an easier target than Java 5
I would at least reconsider that decision if there were sufficient demand for a Java 5 version. But, frankly, I don't see much enthusiasm now even from the Java 6 / 7 camps.
Edit: It seems a JSR 166y (Fork-Join) backport to Java 5 might be doomed.
2) I'm not sure I fully understand your second question. Could you please elaborate a little further?
Cheers,
Stefan
Last edit: Stefan Zobel 2014-08-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Dan: If you want something to play with, I've attached an experimental build for Java 5.
It has seen almost no testing and won't be as efficient as the "official" version. Warning: It might even be not correct!
The j8.u.c.atomic package is missing and the j8.u.c package has been stripped to the necessary. Otherwise, it exhibits the same functionality as the "official" build.
As I said, it won't be possible to "retrotranslate" it to 1.4. Good luck and happy testing!
Thanks Stefan. I will try to reserve some time to experiment with a 1.5 constrained device.
Retrotranslator presents a framework for analysing existing code that hits 1.5 APIs and converts them into instead importing packages from the net.retrotranslator packages. With my second question, I was asking if you'd considered something similar for streamsupport - e.g. where actual java 8 compiled byte code with calls to java.function etc were modified to instead target your java8.function packages.
Last edit: Anonymous 2014-08-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think it would be practicable because the API isn't 100% compatible.
While it would be reasonably easy to rename some bytecode references to use the j8.u. classes, I don't see how the new polymorhic default methods in the Java 8 interfaces could be treated in an automated way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi,
Streamsupport will be really helpful for those of us stuck on older VMs. A lot of older devices exist where a 1.4 JVM is the only option. Investigating using streamsupport with Retrotranslator http://retrotranslator.sourceforge.net in the same was as it currently uses the concurrency back-port might well give this project a grateful additional audience.
Thanks, Dan.
Heaven forbid, that would be a bold venture! I understand your point of view - but I don't think a 1.4 backport would be possible (not at a satisfactory performance level and not as robust as a 1.5 backport might be).
Unfortunately, there is a bit more to it than simply moving default/static interface methods to companion classes and let retrolambda / Retrotranslator do the rest. The streams library (and JSR 166) has a strong dependency on several things:
Given these close ties to the platform I don't expect it to be practical on 1.4 with its broken Java memory model.
Streamsupport doesn't really use some "concurrency back-port", what it uses in some sense IS the Java 8 code, adapted to Java 6 to compensate for missing methods in sun.misc.Unsafe and things like implementation differences in java.lang.Thread.
What's more, for the streams library actually only 5 classes are needed (CountedCompleter, ForkJoinPool, ForkJoinTask, ForkJoinWorkerThread and ThreadLocalRandom) - all the rest is already there in Java 6. These 5 classes had to be reimplemented anyway - even if the target platform would have been Java 7.
All these things would be missing on 1.4. And I don't believe that I could make this working correctly with a JSR 166 backport library like http://backport-jsr166.sourceforge.net/
It was hard enough for Java 6, believe me. I'm not sure what a Java 5 backport would imply, but 1.4 - I'm sorry to say: no way.
Cheers,
Stefan
Last edit: Stefan Zobel 2014-07-30
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi again,
I'm not so aware of the intricacies, so greatly appreciate the thorough explanation. Perhaps you'd indulge some (more) dumb questions?
What is it that Java 6 provides that Java 5 doesn't that causes the minimum JRE selection for streamsupport? (You probably answered this already, but I was hoping to pick it out to aide my understanding). I've only encountered one thing on 1.5 that Retrotranslator wasn't able to provide, the AbstractQueuedSynchronizer - though their support for the 1.5 APIs isn't complete, it's pretty high!
Could it be advantageous to allow "retrotranslating" of JARs to allow developers to continue to use e.g. java.lang.function packages which are then substituted for the java8... packages during translation? Retrotranslator also supports embedding dependencies, both features I've found very useful at one time or another.
Thanks again for streamsupport, I'm looking forward to making much use of it!
Dan.
Hi Dan,
1) I'm not saying that it wouldn't work on Java 5. sun.misc.Unsafe and j.u.c.locks.LockSupport might be a problem if they don't have all the methods needed (maybe even java.lang.Thread - I don't know, it's been a long while since I last looked at the Java 5 sources).
The remaining delta for the runtime API migth well be replenished (btw, AbstractQueuedSynchronizer is available in Java 5). But note: even if there existed a Java 5 version of streamsupport, it wouldn't be feasible to translate it back to a working 1.4 Jar using RetroTranslator for the above mentioned reasons.
I mainly chose Java 6 as the "minimum" JRE because it
I would at least reconsider that decision if there were sufficient demand for a Java 5 version. But, frankly, I don't see much enthusiasm now even from the Java 6 / 7 camps.
Edit: It seems a JSR 166y (Fork-Join) backport to Java 5 might be doomed.
2) I'm not sure I fully understand your second question. Could you please elaborate a little further?
Cheers,
Stefan
Last edit: Stefan Zobel 2014-08-01
@Dan: If you want something to play with, I've attached an experimental build for Java 5.
It has seen almost no testing and won't be as efficient as the "official" version. Warning: It might even be not correct!
The j8.u.c.atomic package is missing and the j8.u.c package has been stripped to the necessary. Otherwise, it exhibits the same functionality as the "official" build.
As I said, it won't be possible to "retrotranslate" it to 1.4. Good luck and happy testing!
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thanks Stefan. I will try to reserve some time to experiment with a 1.5 constrained device.
Retrotranslator presents a framework for analysing existing code that hits 1.5 APIs and converts them into instead importing packages from the net.retrotranslator packages. With my second question, I was asking if you'd considered something similar for streamsupport - e.g. where actual java 8 compiled byte code with calls to java.function etc were modified to instead target your java8.function packages.
Last edit: Anonymous 2014-08-11
I don't think it would be practicable because the API isn't 100% compatible.
While it would be reasonably easy to rename some bytecode references to use the j8.u. classes, I don't see how the new polymorhic default methods in the Java 8 interfaces could be treated in an automated way.