RFR: [8218152] javac fails and exits with no error if a bad annotation processor is on the classpath
Jan Lahoda
jan.lahoda at oracle.com
Mon Mar 4 11:57:45 UTC 2019
Hi Steve,
On 1.3.2019 15:00, Steve Groeger wrote:
> Hi Jan,
>
> Sorry for the delay in getting back to you on this, but I got dragged
> onto another project which
> delayed me working on this .
>
> Quick question about having binary files in the repository. I had a look
> at the example you mentioned,
> test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
>
> and see that it is using JavacTask() to compile the class. However in my
> tests cases they are using .jar files
> and some of the classes included in the jar files are not real classes
> or a classes that have been built with a
> later version of java than is being tested. In these cases it is
> difficult to build these as part of the tests
> (unless you know how this can be done).
I don't think the tests really need jars - directories should work in
the same way (but ToolBox allows to create jars as well if needed).
Also, seems the current tests only test malformed processor classfiles
and missing processors, which should be easy to do in any case. A
possible test:
http://cr.openjdk.java.net/~jlahoda/8218152/MalformedAP.java
(It also tests a Processor classfile that has unsupported major version.)
>
> I did also notice, although you said binary files should not be in the
> repository, that the existing repository
> has lots of binary files, which seem to be jar files. So is it a
> definite that binary files are not allowed or only
> in ceratin circumstances. If the latter would it be OK to have the jar
> files in my webrev in the repo?
$ find . -type f -name "*.jar" | grep -v "./build/" | wc -l
in the top-level directory returns 61 for me, and looking at the history
of some of them, it seems they are very old, so I'd consider them
legacy. In this case, it seems fairly easy to do without these files
(and maybe even easier without them), so I personally don't see a reason
to include them.
Thanks,
Jan
>
> Thanks
> Steve Groeger
> IBM Runtime Technologies
> Hursley, Winchester
> Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> Fax (44) 1962 816800
> Lotus Notes: Steve Groeger/UK/IBM
> Internet: groeges at uk.ibm.com
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> From: Jan Lahoda <jan.lahoda at oracle.com>
> To: Steve Groeger <GROEGES at uk.ibm.com>
> Cc: compiler-dev at openjdk.java.net
> Date: 13/02/2019 15:10
> Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad
> annotation processor is on the classpath
> ------------------------------------------------------------------------
>
>
>
> On 13.2.2019 10:58, Steve Groeger wrote:
> > Hi Jan,
> >
> > Thanks for the response.
> >
> > With regards to your comments re:
> >
> > >But I guess I'd personally rather kept
> > >it simple. Would there be an issue with simply changing the "catch
> > >(Throwable)" to also report the same error as "catch
> > >(ServiceConfigurationError)"? I.e. something like:
> > >>---
> > >> diff -r 4ef401769c36
> >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > >> ---
> >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > Fri Feb 08 14:06:35 2019 +0100
> > >> +++
> >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > Mon Feb 11 13:33:50 2019 +0100
> > >> @@ -437,6 +437,7 @@
> > >>
> > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
> > >> throw new Abort(sce);
> > >> } catch (Throwable t) {
> > >> +
> > log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
> > >> throw new Abort(t);
> > >> }
> > >> }
> > >> @@ -453,6 +454,7 @@
> > >>
> > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
> > >> throw new Abort(sce);
> > >> } catch (Throwable t) {
> > >> +
> > log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
> > >> throw new Abort(t);
> > >> }
> > >> }
> > >---
> >
> > I can do it the waty you sugegsted but I had done it this way because
> > Jonathan Gibbons had stated:
> >
> > >> There's a `catch (Throwable t)` in the same set of catch blocks
> that you
> > >> did not update. Rather than add yet another message for that case, it
> > >> might be better to throw FatalError, to provoke the standard "javac
> > >> crash" output for the unknown exception.
> >
> > Either way is OK with me. We just need to make a decision on which is
> > the preferred way - then I can update the webrevs.
>
> To me personally, FatalError feels a little bit harsh. But I agree we
> should try to avoid adding new error messages for this if possible. I'll
> leave it up to Jon.
>
> (If we wanted to always print a stack trace for these problems, we could
> change to code to simply throw AnnotationProcessingError, which always
> prints the stacktrace - some tweaking to make the errors look good might
> be needed, though.)
>
> Jan
>
> >
> > >Looking at the tests, one thing to note is that binary files are
> > >generally not allowed in the repository. I wonder if a test that would
> > >run javac programmaticaly wouldn't be easier to do
> >
> > I will take yopur advice on the tests and see if I can do this
> > programtically rather than havng the binary files in the repository.
> >
> > Will post again in the mailing list when I have updated webrevs that are
> > suitable for being reviewed.
> >
> > Thanks
> > Steve Groeger
> > IBM Runtime Technologies
> > Hursley, Winchester
> > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> > Fax (44) 1962 816800
> > Lotus Notes: Steve Groeger/UK/IBM
> > Internet: groeges at uk.ibm.com
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
> >
> >
> >
> > From: Jan Lahoda <jan.lahoda at oracle.com>
> > To: Steve Groeger <GROEGES at uk.ibm.com>, compiler-dev at openjdk.java.net
> > Date: 11/02/2019 12:45
> > Subject: Re: RFR: [8218152] javac fails and exits with no error if a bad
> > annotation processor is on the classpath
> > ------------------------------------------------------------------------
> >
> >
> >
> > Hi Steve,
> >
> > I apologize for a late reply.
> >
> > One thing to note is that according to the ServiceLoader spec, the
> > LinkageErrors shouldn't be thrown out of the Iterator. That is my
> > reading at least. Please see:
> > https://bugs.openjdk.java.net/browse/JDK-8196182
> >
> > Given there are some issues associated with that, I don't see a problem
> > with workarounding that in javac. But I guess I'd personally rather kept
> > it simple. Would there be an issue with simply changing the "catch
> > (Throwable)" to also report the same error as "catch
> > (ServiceConfigurationError)"? I.e. something like:
> > ---
> > > diff -r 4ef401769c36
> >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > > ---
> >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > Fri Feb 08 14:06:35 2019 +0100
> > > +++
> >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > Mon Feb 11 13:33:50 2019 +0100
> > > @@ -437,6 +437,7 @@
> > >
> > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
> > > throw new Abort(sce);
> > > } catch (Throwable t) {
> > > +
> > log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
> > > throw new Abort(t);
> > > }
> > > }
> > > @@ -453,6 +454,7 @@
> > >
> > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
> > > throw new Abort(sce);
> > > } catch (Throwable t) {
> > > +
> > log.error(Errors.ProcBadConfigFile(t.getLocalizedMessage()));
> > > throw new Abort(t);
> > > }
> > > }
> > ---
> >
> > Looking at the tests, one thing to note is that binary files are
> > generally not allowed in the repository. I wonder if a test that would
> > run javac programmaticaly wouldn't be easier to do, see e.g.:
> >
> test/langtools/tools/javac/processing/rounds/GetElementsAnnotatedWithOnMissing.java
> >
> > This should allow arbitrary changes to the classfiles, so that binaries
> > don't need to be in the repository.
> >
> > Thanks,
> > Jan
> >
> > On 11.2.2019 12:30, Steve Groeger wrote:
> > > Hi all,
> > >
> > > Is there anyone out there that would be able to review the webrevs
> > > mentioned in the earlier post.
> > > Jonathan Gibbons has agreed to sponsor these changes but we need 2
> > > reviewers. Anyone?
> > >
> > > Thanks
> > > Steve Groeger
> > > IBM Runtime Technologies
> > > Hursley, Winchester
> > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> > > Fax (44) 1962 816800
> > > Lotus Notes: Steve Groeger/UK/IBM
> > > Internet: groeges at uk.ibm.com
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > >
> > >
> > >
> > > From: Steve Groeger <GROEGES at uk.ibm.com>
> > > To: compiler-dev at openjdk.java.net
> > > Date: 01/02/2019 12:47
> > > Subject: RFR: [8218152] javac fails and exits with no error if a bad
> > > annotation processor is on the classpath
> > > Sent by: "compiler-dev" <compiler-dev-bounces at openjdk.java.net>
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Hi all,
> > >
> > > I have made some changes to the code for issue [1] for both jdk8u and
> > > jdk (jdk13)
> > > The latest webrevs have a few extra changes suggested by Jonathan
> > > Gibbons mentioned in an earlier mailing [2]
> > > The webrevs are for jdk8u [3] and for jdk [4].
> > > Please could someone review these changes and let me know if there are
> > > any issues.
> > >
> > > [1]
> >
> _https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
> > > [2]
> > >
> >
> _https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openjdk.java.net_pipermail_compiler-2Ddev_2019-2DJanuary_012920.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=AhWE854aM6al5na1Eo9sxF4IoWBZC3jfvLHRo2a2ETo&e=
> > > [3]
> >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=OM__1ZIlBCUXiHNLfltEv9c_6a8k8nspR0KnKjRT8II&e=
> > > [4]
> >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.01_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=HrpL5tvveJrGX0ABN9uGRn0bZV1nsiNxzuLOAVem3Z0&e=
> > >
> > > Thanks
> > > Steve Groeger
> > > IBM Runtime Technologies
> > > Hursley, Winchester
> > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> > > Fax (44) 1962 816800
> > > Lotus Notes: Steve Groeger/UK/IBM
> > > Internet: groeges at uk.ibm.com
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > >
> > >
> > >
> > > From: Jonathan Gibbons <jonathan.gibbons at oracle.com>
> > > To: Steve Groeger <GROEGES at uk.ibm.com>
> > > Cc: compiler-dev at openjdk.java.net
> > > Date: 31/01/2019 16:56
> > > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
> > > annotation processor is on the classpath
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Steve,
> > >
> > > When you post the new webrevs, can I suggest that you change the
> Subject
> > > line of this thread to something like
> > >
> > > RFR: 8218152 [javac] fails and exits with no error if a bad annotation
> > > processor provided
> > >
> > > That will help get attention from reviewers, and help any subsequent
> > > bug-archaeology.
> > >
> > > I can sponsor the changes for you once they have been reviewed.
> > >
> > > -- Jon
> > >
> > > On 1/31/19 8:49 AM, Steve Groeger wrote:
> > > Hi Jonathan,
> > >
> > > Thanks for responding.
> > >
> > > I have created a couple of webrevs for jdk8u [1] and jdk [2] which
> also
> > > include some JTReg tests.
> > > I would be grateful if you, or someone else could review these just to
> > > ensure I am doing the right thing.
> > > I will update the code with the additional 'throw FatalError' that you
> > > mentioned and will then create some new webrevs
> > >
> > > If you are able to sponsor these changes for me I would be very
> grateful.
> > >
> > > PS. As you saw I have created a JBS issue for this here [3]
> > >
> > > [1]
> >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk8u_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=JoEgW12V0tuoZvuG9GDF7g5YmXhjGolWyibAYlifWME&e=
> > > [2]
> >
> _https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Esgroeger_8218152_jdk_webrev.00_-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=NeM6uUrEq-vcqXQ5uHonCor_ChwsY20notpASJS4is8&e=
> > >
> >
> [3_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8218152-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=78GW2OHz7nNTH2dBkTx7-TKh2QCt3JD3zukzeUO8RpA&m=3eyXaufRP0Xc78gxZMprIOVTveYQ-jSaXZglJ3ZxTMo&s=GXmb6NEDC3BhXyEw8uaNod2uN_hYX-9HpHkoiGhEujY&e=
> > >
> > > Thanks
> > > Steve Groeger
> > > IBM Runtime Technologies
> > > Hursley, Winchester
> > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> > > Fax (44) 1962 816800
> > > Lotus Notes: Steve Groeger/UK/IBM
> > > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > >
> > >
> > >
> > > From: Jonathan Gibbons _<jonathan.gibbons at oracle.com>_
> > > <mailto:jonathan.gibbons at oracle.com>
> > > To: Steve Groeger _<GROEGES at uk.ibm.com>_ <mailto:GROEGES at uk.ibm.com>,
> > > _compiler-dev at openjdk.java.net_ <mailto:compiler-dev at openjdk.java.net>
> > > Date: 31/01/2019 16:33
> > > Subject: Re: [NEW_BUG] javac fails and exits with no error if a bad
> > > annotation processor is on the classpath
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Steve,
> > >
> > > Your fix is generally good: Abort should only be used after a suitable
> > > message has been reported.
> > >
> > > There's a `catch (Throwable t)` in the same set of catch blocks
> that you
> > > did not update. Rather than add yet another message for that case, it
> > > might be better to throw FatalError, to provoke the standard "javac
> > > crash" output for the unknown exception.
> > >
> > > You should provide a test case ... i.e. as a jtreg test.
> > >
> > > -- Jon
> > >
> > > On 1/29/19 3:18 AM, Steve Groeger wrote:
> > > Hi all,
> > >
> > > I have identified a potential issue where javac fails and exits
> with no
> > > error if a bad annotation processor is on the classpath.
> > >
> > > Background: an Annotation Processor class can be packaged in a jar
> file
> > > and is identified by a special text file inside the jar named:
> > > META-INF/services/javax.annotation.processing.Processor. This text
> file
> > > has only one line, specifying the class name of the annotation process
> > > class to run. When javac runs, it checks all jars on the classpath and
> > > if it finds the special text file in any jar file, then it attempts to
> > > run the class listed there.
> > >
> > > The issue here is that when the annotation processor class can't be
> > > executed, javac catches the exception and exits without reporting
> on the
> > > reason for the exit. Examples of reasons why the annotation processor
> > > can't be executed include:
> > >
> > > * the annotation processor class is compiled for a higher version of
> > > Java than the javac is running, giving
> UnsupportedClassVersionError.
> > > * the annotation processor class file is corrupt so can't be loaded.
> > >
> > >
> > > In either of the above cases javac will swallow the error and exit
> > > without telling the user why it failed to compile the java source code
> > > as expected.
> > >
> > > Testcase
> > > put HelloWorld.java in current directory, edit <path_to_jar>
> and run:
> > > javac -cp .:<path_to_jar>/bad.annotation.processor.jar
> > > HelloWorld.java
> > >
> > > Instead of producing HelloWorld.class as expected, javac exits
> silently.
> > >
> > > Here, bad.annotation.processor.jar is a file that I created to
> contain:
> > > META-INF/services/javax.annotation.processing.Processor <<--
> text
> > > file to list bad class
> > > bad/notaclass.class <<-- dummy file, can't be loaded as a
> java class
> > >
> > > Does anyone know whether this is a bug and that this should throw an
> > > error in these cases?
> > > If so, I will raise a bug for this.
> > >
> > > I have looked at the code and seen where javac Aborts the processing,
> > > and if I make the following changes the javac detects the issue and
> > > reports an error before Aborting.
> > >
> > > diff -r 5178e4b58b17
> > >
> >
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > > ---
> > >
> >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > > Mon Jan 28 09:56:00 2019 +0100
> > > +++
> > >
> >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java
> > > Tue Jan 29 11:14:57 2019 +0000
> > > @@ -1,5 +1,5 @@
> > > /*
> > > - * Copyright (c) 2005, 2018, Oracle and/or its affiliates. All rights
> > > reserved.
> > > + * Copyright (c) 2005, 2019, Oracle and/or its affiliates. All rights
> > > reserved.
> > > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> > > *
> > > * This code is free software; you can redistribute it and/or
> modify it
> > > @@ -436,6 +436,12 @@
> > > } catch(ServiceConfigurationError sce) {
> > >
> > > log.error(Errors.ProcBadConfigFile(sce.getLocalizedMessage()));
> > > throw new Abort(sce);
> > > + } catch (UnsupportedClassVersionError ucve) {
> > > +
> > > log.error(Errors.ProcCantLoadClass(ucve.getLocalizedMessage()));
> > > + throw new Abort(ucve);
> > > + } catch (ClassFormatError cfe) {
> > > +
> > > log.error(Errors.ProcCantLoadClass(cfe.getLocalizedMessage()));
> > > + throw new Abort(cfe);
> > > } catch (Throwable t) {
> > > throw new Abort(t);
> > > }
> > >
> > > and to add a new message there is this change
> > >
> > > diff -r 5178e4b58b17
> > >
> >
> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> > > ---
> > >
> >
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> > > Mon Jan 28 09:56:00 2019 +0100
> > > +++
> > >
> >
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
> > > Tue Jan 29 11:16:03 2019 +0000
> > > @@ -1,5 +1,5 @@
> > > #
> > > -# Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights
> > > reserved.
> > > +# Copyright (c) 1999, 2019, Oracle and/or its affiliates. All rights
> > > reserved.
> > > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> > > #
> > > # This code is free software; you can redistribute it and/or modify it
> > > @@ -1051,6 +1051,10 @@
> > > compiler.err.proc.cant.find.class=\
> > > Could not find class file for ''{0}''.
> > >
> > > +# 0: string
> > > +compiler.err.proc.cant.load.class=\
> > > + Could not load processor class file due to ''{0}''.
> > > +
> > > # Print a client-generated error message; assumed to be localized, no
> > > translation required
> > > # 0: string
> > > compiler.err.proc.messager=\
> > >
> > >
> > > If this is deemed a bug and the change seems OK, please could someone
> > > sponsor this for me and I will create a proper webrev for the
> change for
> > > a full review.
> > >
> > > Thanks
> > > Steve Groeger
> > > IBM Runtime Technologies
> > > Hursley, Winchester
> > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
> > > Fax (44) 1962 816800
> > > Lotus Notes: Steve Groeger/UK/IBM
> > > Internet: _groeges at uk.ibm.com_ <mailto:groeges at uk.ibm.com>
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > >
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > >
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> > >
> > >
> > > Unless stated otherwise above:
> > > IBM United Kingdom Limited - Registered in England and Wales with
> number
> > > 741598.
> > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> > PO6 3AU
> >
> >
> >
> >
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the compiler-dev
mailing list