Skip to content

Initial code migration #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 15 commits into from
Apr 13, 2017
Merged

Initial code migration #1

merged 15 commits into from
Apr 13, 2017

Conversation

hiranya911
Copy link
Contributor

@hiranya911 hiranya911 commented Apr 7, 2017

It's quite a few commits, but this is the gist of it:

  • All source files have been formatted to the satisfaction of the maven-checkstyle-plugin. This involved renaming many variables, rearranging many imports, re-indenting most source files and updating some javadocs.
  • Check style plugin configured to run with the build. Any lint errors will break the build.
  • All crypto artifacts (private keys, certificates etc.) have been scrubbed from the repo. They shouldn't be present in the Git history either. Updated tests to use a new set of mock crypto artifacts where necessary.
  • Went through all test cases, and re-enabled all unit test cases. They are all passing.
  • Legacy integration tests have been removed temporarily. I've added 2 of these back with some modifications to ensure we have support in Maven to run integration tests.

To run the linter by itself: mvn validate
To run unit tests only: mvn test
To run unit and integration tests: mvn verify -Dfirebase.it.certificate={PathToCertFile} -Dfirebase.it.url={FirebaseDbUrl}

@hiranya911
Copy link
Contributor Author

New files added:

  • pom.xml
  • checkstyle.xml
  • Everything under src/test/resources/service_accounts
  • IntegrationTestUtils.java
  • FirebaseDatabaseTestIT.java (based on FirebaseDatabaseTest legacy integration test)
  • FirebaseDatabaseAuthTestIT.java (based on DatabaseServerAuthTest legacy integration test)

Files removed:

  • All legacy integration tests

Copy link

@jwngr jwngr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, so I took a crack at reviewing this. It's huge! I honestly don't think it's going to be reasonable to review the source and test files since it's impossible to know what changed. From what I can tell, it was only linting changes and changes required to use new mocked keys. Given that, I think I'm cool with what's in here. But I do have a slight worry about possible minor bugs introduced from the linting changes. Those are going to be pretty difficult to find in this CL. What do you guys think?

@@ -0,0 +1,12 @@
{
"type": "service_account",
"project_id": "mock-project-id",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be mock-project-id-owner? I see you use this in client_x509_cert_url, but nowhere else in this file. Should we also update client_email?

@@ -0,0 +1,12 @@
{
"type": "service_account",
"project_id": "mock-project-id",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should you add -none to project_id and client_email?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're right about the client_email. project_id can be the same for all users.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the existing way is correct. These credentials are supposed to be for a set of users (with different privileges) on the same project. I've checked that client_email and cert_url fields are different for each user.

@@ -0,0 +1,12 @@
{
"type": "service_account",
"project_id": "mock-project-id",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should you add -editor to project_id and client_email?

@mikelehen
Copy link

@schmidt-sebastian once fixed hundreds of lint errors in our Android codebase and to verify the correctness, he and BenWu decompiled the jars and compared the code. Can we do the same thing here?

@hiranya911
Copy link
Contributor Author

Michael, that was an excellent suggestion. I ran a Java binary compatibility checker on 4.1.6 (last release) and the latest build from Github, and uncovered a couple of changes that shouldn't have been made. I'm making the appropriate fixes now.

@hiranya911
Copy link
Contributor Author

compat_reports.zip

I'm attaching the report generated by the binary compatibility checker. After the latest fixes the compatibility level is 98.3%. You can see the report by extracting the attached zip, and opening the file compat_reports/firebase-admin/4.1.6_to_4.1.7-SNAPSHOT/compat_report.html in a web browser.

The only reported changes are due to me renaming some type variables. For example types like Task<TResult> were renamed to Task<T> to meet style requirements. The binary compatibility checker report them as incompatibilities for some reason. The only other change is removal of ThreadBackgroundExecutor.java. But this was an empty class to begin with, and didn't have any code.

@hiranya911
Copy link
Contributor Author

Jacob, take a look at the binary diff report I've attached. I think it shows that there is no noticeable change at the binary level. So I think we should be good to go. We also have reasonable amount of unit tests, all of which passes. Plus, I've been working on porting the legacy integration tests, and most of them work when pointed to Firebase prod.

@schmidt-sebastian
Copy link
Contributor

Jacob, take a look at the binary diff report I've attached. I think it shows that there is no noticeable change at the binary level. So I think we should be good to go. We also have reasonable amount of unit tests, all of which passes. Plus, I've been working on porting the legacy integration tests, and most of them work when pointed to Firebase prod.

This checker (if I understand correctly) checks for changes in the API surface. That is not enough unfortunately. As @mikelehen pointed out, the way we checked this when I cleaned up the code for G4 compatibility was to create jar files and decompile them. Your diff will likely still be considerable since you renamed variables, but I don't think there is any other way.

This commit will also break our ability to merge changes from Android directly, but I think that's fine for now.

@hiranya911
Copy link
Contributor Author

I ran another binary diff tool (pkgdiff) which compares compiled class files all the way down to the instructions. According to this tool the difference between v4.1.6 and latest snapshot is 4.3%. I need to run this again on a Linux environment, to be able to see the detailed diff output. Will do that tomorrow.

@hiranya911
Copy link
Contributor Author

hiranya911 commented Apr 11, 2017

Attaching the pkgdiff reports. I'm still sifting through the data. Will report on my findings. File to look for is pkgdiff_reports/firebase-admin/4.1.6_to_4.1.7-SNAPSHOT/changes_report.html

pkgdiff_reports.zip

@hiranya911
Copy link
Contributor Author

Here's a diff report between decompiled sources:

X_to_Y.zip

@hiranya911
Copy link
Contributor Author

I've gone through the diff report for the decompiled sources. I'm not seeing any changes that can result in API or behavior changes. In general, the reported diff's are due to following reasons:

  • Order of methods changing in source files.
  • Variable renaming.
  • Differences in how the 2 versions of Java compiler handles string concatenation and anonymous classes (the snapshot was built using JDK 1.8).

The only functional diff I saw was in the GaeThreadFactory class, but this is due to a change we merged to the codebase after 4.1.6 release.

Copy link

@jwngr jwngr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I took a look at the latest diff report you generated and it looked like there was feature parity between the old and new and it's comforting that all our test suites pass. I do think someone like @schmidt-sebastian with some more Java background should take a look to triple check this though before we merge it in.

@jwngr jwngr assigned schmidt-sebastian and unassigned jwngr Apr 12, 2017
@schmidt-sebastian
Copy link
Contributor

I spot checked a fair number of files in X_to_Y and the diff looks good to me. Thanks for being so thorough!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants