Hi Ken,

I don't mean to scare you, but you're running on a very old version of
Groovy (1.7.5 is from 2010 !), which has several vulnerabilities. Anyway,
if you still want to do this, there are things you need to know:

1. the build was using Ant at this time, and not especially known to be
reproducible.
2. as you saw, the build missed some critical configuration like file
encoding, but by then some files were also encoded using different
encodings if I remember well
3. the compiler, especially by then, wasn't checked for reproducibility,
and for Groovy file at least, introduced some timestamps in binary class
files, making it by design not reproducible
4. even recent versions of the Groovy compiler had bugs that made outputs
non reproducible (runtime was, but the binary wasn't: this can happen if
you have to choose between 2 interfaces which provide the same method, and
you arbitrarily choose to call one over the other)
5. backporting a change like the GROOVY-5249, which was written for Groovy
2.3, looks very difficult at first glance: there were *many* changes in the
MOP in Groovy 2

So I don't want to kill your efforts, but I'm wondering if you really have
no other choice.

2018-02-08 12:33 GMT+01:00 Ken Lam <ken....@mobigator.com>:

> Dear Groovy developers,
>
> After experimenting with many JDK versions, I found that JDK 6 Update 13
> and 21 to be able to build the jar with the least difference from the
> official groovy-all-1.7.5.jar distributed in grails 1.3.5.
>
> But I still want to know whether the difference in the binary .class files
> will have impact to my system.
>
> Attached are the samples and summary of "how different" the jar built by
> me is from the official groovy-all-1.7.5.jar
>
> JDK 6 Update 13: 190 binary files different from official version
>
> JDK 6 Update 21: 198 binary files different from official version
>
>
> Apart from the "__timeStamp__239_neverHappen" timestamp in the .class
> files, there are still some other differences, and I want to know why they
> are here.
>
> I understand this is a lot to ask, but I have no choice because I don't
> know how to analyze the bytecode differences and their meanings. So I have
> attached some samples and I hope if you can teach me some basic knowledge
> and some references to look at, I will be able to handle it myself in the
> future.
>
> Regards,
>
> Ken Lam
> System Analyst
> Mobigator Technology Group
> http://www.mobigator.com
> T: +852.2524.9000, ext 114
> F: +852.2524.9050
>
> -------- Original Message --------
> Subject: Re: Need to get help: Building Groovy 1.7.5 from source gives
> encoding error for ReadLineTest.groovy
> From: Ken Lam <ken....@mobigator.com>
> To: users@groovy.apache.org, Jochen Theodorou <blackd...@gmx.org>
> Date: 8/2/2018 11:18
>
>> Dear Jochen,
>>
>> More info I found from MANIFEST.MF:
>>
>> I found that the official groovy-all-1.7.5.jar distributed in grails
>> 1.3.5 was built with JDK 1.7.0-ea (Sun Microsystems Inc.). I guess the "ea"
>> means early access version. So I don't believe I could ever use the exactly
>> same JDK to compile the groovy source. How am I supposed to find an early
>> access version?
>>
>> Anyway, this is a less important question. As mentioned in previous
>> email, I mainly want to know whether it's expected or required, to compile
>> binary .class files which are identical to the officially distributed ones,
>> when we try to rebuild groovy on our own.
>>
>> Regards,
>>
>> Ken Lam
>> System Analyst
>> Mobigator Technology Group
>> http://www.mobigator.com
>> T: +852.2524.9000, ext 114
>> F: +852.2524.9050
>>
>> -------- Original Message --------
>> Subject: Re: Need to get help: Building Groovy 1.7.5 from source gives
>> encoding error for ReadLineTest.groovy
>> From: Ken Lam <ken....@mobigator.com>
>> To: users@groovy.apache.org, Jochen Theodorou <blackd...@gmx.org>
>> Date: 8/2/2018 11:12
>>
>>> Dear Jochen,
>>>
>>> Also, after compiling the groovy-all-1.7.5.jar, I extracted the jar, and
>>> extracted the official jar distributed in grails 1.3.5, and compare between
>>> the two extracted folders.
>>>
>>> Out of 3371 files, 256 files (254 binary files + 2 text files) are
>>> different, and the rest are identical.
>>>
>>> For the 2 different text files, I have checked and they should be ok.
>>>
>>> For the 254 binary files, however, I am not sure whether this is normal.
>>>
>>> Of course, I haven't modified any source codes at all. At least not yet.
>>>
>>>
>>> My question is:
>>>
>>> Is it expected or required, to have exact binary .class files compiled
>>> when we try to rebuild groovy? My compiled jar does have nearly 3000 binary
>>> class files being identical to the those in the official jar, only 254
>>> binary files are different.
>>>
>>> Regards,
>>>
>>> Ken Lam
>>> System Analyst
>>> Mobigator Technology Group
>>> http://www.mobigator.com
>>> T: +852.2524.9000, ext 114
>>> F: +852.2524.9050
>>>
>>> -------- Original Message --------
>>> Subject: Re: Need to get help: Building Groovy 1.7.5 from source gives
>>> encoding error for ReadLineTest.groovy
>>> From: Jochen Theodorou <blackd...@gmx.org>
>>> To: users@groovy.apache.org
>>> Date: 8/2/2018 4:11
>>>
>>>> On 07.02.2018 07:12, Ken Lam wrote:
>>>>
>>>>> Dear Jochen,
>>>>>
>>>>> Then why do I have to set
>>>>>
>>>>> encoding="utf-8"
>>>>>
>>>>> in groovyc commands in the build.xml to force it to UTF-8,
>>>>>
>>>>
>>>> If no encoding is set, the system encoding is used and that could be
>>>> for example GB2312 or Big5 or even only ASCII
>>>>
>>>> while the official source distribution can omit this and the Groovy
>>>>> developers can still compile the source of Groovy 1.7.5 correctly?
>>>>>
>>>>
>>>> because we work on linux and mac systems. I am using UTF8 as system
>>>> default for over 10 years now.
>>>>
>>>> Which settings in the system am I missing?
>>>>>
>>>>
>>>> On Windows? sorry, cannot help here really. Windows is not know to be
>>>> friendly to such changes at all.
>>>>
>>>> bye Jochen
>>>>
>>>
>>>
>>
>

Reply via email to