>From what I understand, the Java 8 -> 11 testing isn't in essence similar to py2 -> py3 checks. In the case of Java, all we want to do is check if Beam downloaded by users from Maven (and compiled with JDK8) won't act up if used from a JDK/JRE 11 environment. We don't want to migrate the tool itself to a newer language version. As I mentioned in my previous email, there already are test suites checking compatibility - ValidatesRunner on Direct and Dataflow runners running in normal and portable mode. Those tests keep passing, so I believe we're mostly fine regarding compatibility. All I want to know is - is this enough? How else can we test Beam to be sure it works in JRE 11? After several accidental launches of build tasks in JDK 11, I am sure that it's not buildable with it, but this is not the compatibility type we want to check.
Thank you for your replies, Michal On Thu, Aug 8, 2019 at 10:25 PM Valentyn Tymofieiev <valen...@google.com> wrote: > From Python 3 migration standpoint, some high level pillars that increase > our confidence are: > - Test coverage: (PreCommit, PostCommit), creating a system to make it > easy for add test coverage in new language for new functionality. > - Support of new language version by core runners + ValidatesRunner test > coverage. > - Test of time: offer new functionality in a few releases, monitor & > address user feedback. > > Dependency audit and critical feature support in new language, as > mentioned by others, are important points. If you are curious about > detailed AIs that went into Python 3 support, feel free to look into > BEAM-1251 or Py3 Kanban Board ( > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=245&view=detail > ). > > Thanks, > Valentyn > > > On Thu, Aug 8, 2019 at 7:24 PM Mark Liu <mark...@google.com> wrote: > >> Some actions we did for py2 to py3 works: >> - Check and resolve incompatible dependencies. >> - Enable py3 lint. >> - Fill feature gaps between py2 and py3 (e.g. new py3 container, new >> solution for type hint) >> - Add unit tests, integration tests and other tests on py3 for coverage. >> - Release (p3) and deprecation (p2) plan. >> >> Hope this helps on Java upgrade. >> >> Mark >> >> On Wed, Aug 7, 2019 at 3:19 PM Ahmet Altay <al...@google.com> wrote: >> >>> >>> >>> On Wed, Aug 7, 2019 at 12:21 PM Elliotte Rusty Harold < >>> elh...@ibiblio.org> wrote: >>> >>>> gRPC bug here: https://github.com/grpc/grpc-java/issues/3522 >>>> >>>> google-cloud-java bug: >>>> https://github.com/googleapis/google-cloud-java/issues/5760 >>>> >>>> Neither has a cheap or easy fix, I'm afraid. Commenting on these >>>> issues might help us prove that there's a demand to priorotize these >>>> compared to other work. If anyone has a support contract and could >>>> file a ticket asking for a fix, that would help even more. >>>> >>>> Those are the two I know about. There might be others elsewhere in the >>>> dependency tree. >>>> >>>> >>>> On Wed, Aug 7, 2019 at 2:25 PM Lukasz Cwik <lc...@google.com> wrote: >>>> > >>>> > Since java8 -> java11 is similar to python2 -> python3 migration, >>>> what was the acceptance criteria there? >>>> >>> >>> I do not remember formally discussing this. The bar used was, all >>> existing tests will pass for python2 and python3. New tests will be added >>> for python3 specific features. (To avoid any confusion this bar has not >>> been cleared yet.) >>> >>> cc: +Valentyn Tymofieiev <valen...@google.com> could add more details. >>> >>> >>>> > >>>> > On Wed, Aug 7, 2019 at 1:54 PM Elliotte Rusty Harold < >>>> elh...@ibiblio.org> wrote: >>>> >> >>>> >> >>>> >> >>>> >> On Wed, Aug 7, 2019 at 9:41 AM Michał Walenia < >>>> michal.wale...@polidea.com> wrote: >>>> >>> >>>> >>> >>>> >>> Are these tests sufficient to say that we’re java 11 compatible? >>>> What other aspects do we need to test to be able to say that? >>>> >>> >>>> >>> >>>> >> >>>> >> Are any packages split across multiple jar files, including packages >>>> beam dependns on? That's the one that's bitten some other projects, >>>> including google-cloud-java and gRPC. If so, beam is not going to work with >>>> the module system. >>>> >> >>>> >> Work is ongoing to fix splitn packages in both gRPC and >>>> google-cloud-java, but we're not very far down that path and I think it's >>>> going to be an API breaking change. >>>> >> >>>> > Romain pointed this out earlier and I fixed the last case of packages >>>> being split across multiple jars within Apache Beam but as you point out >>>> our transitive dependencies are not ready. >>>> >> >>>> >> >>>> >> -- >>>> >> Elliotte Rusty Harold >>>> >> elh...@ibiblio.org >>>> >>>> >>>> >>>> -- >>>> Elliotte Rusty Harold >>>> elh...@ibiblio.org >>>> >>> -- Michał Walenia Polidea <https://www.polidea.com/> | Software Engineer M: +48 791 432 002 <+48791432002> E: michal.wale...@polidea.com Unique Tech Check out our projects! <https://www.polidea.com/our-work>
