Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Proposals for version 3 #637

Closed
PatrickGotthard opened this issue Feb 28, 2023 · 8 comments
Closed

Proposals for version 3 #637

PatrickGotthard opened this issue Feb 28, 2023 · 8 comments

Comments

@PatrickGotthard
Copy link
Member

PatrickGotthard commented Feb 28, 2023

Here are some proposals for version 3:

  • remove Cloneable
  • remove Serializable
  • replace reflection (e.g. in equals and hashCode) with explicit code
  • replace rome.properties through ServiceLoader
  • replace JDOM with Java DOM or StAX
  • integrate all modules into "rome" (effectively only rome-modules and rome-opml will be integrated)
  • remove URL support from XmlReader
  • support for JSR 310 (new Date Time API)
@antoniosanct
Copy link
Contributor

Hi, @PatrickGotthard

Nice to try the first three! Maybe the old JDK DOM migration (or maybe StAX parser!) could be a nice chance to include it. Branch reorganization seems a big problem at this moment for JDK DOM migration in my forked repo (>600 files changed). Step by step.

Regards,
Antonio.

@artembilan
Copy link
Contributor

I would suggest to stay away from Lombok: you develop here a library, not the target application, so better to be as specific with your code as possible.
And less reflection, please! 😄

@PatrickGotthard PatrickGotthard pinned this issue Mar 1, 2023
@neroux
Copy link
Contributor

neroux commented Mar 7, 2023

As I mentioned previously, please make sure you are not breaking Android compatibiity with these changes, otherwise the library would become unusable.

The DOM change was mentioned at some point and the date API may be also an issue, even though I believe this was addressed.

@antoniosanct
Copy link
Contributor

@neroux how could I check if Android or ASOP have Java DOM compatibility?
@PatrickGotthard JSR 310, How could I start? (hehe!)

Regards,
Antonio.

@antoniosanct
Copy link
Contributor

@PatrickGotthard Yesterday I started migrating all Date/Calendar/DateFormat/SimpleDateFormat references by ZonedDateTime/DateTimeFormatter, and I had some problems using Google Base module. I hope I make a new PR ASAP of this feature.

Regards,
Antonio.

@PatrickGotthard
Copy link
Member Author

Hi @antoniosanct,

I'm glad about your commitment, but please wait a little bit. All above are just ideas without digging deeper into the code. Before breaking backwards-compatibility we should discuss it 🙂

Regarding the Android question: just try it out using the official IDE and SDK 😏

Regards,
Patrick

@antoniosanct
Copy link
Contributor

Hi, everyone:

@neroux I found this link about it: https://developer.android.com/reference/org/w3c/dom/package-summary. I think that AOSP has DOM compatibility, but in all Android versions?
@PatrickGotthard I've finished the feature, but I agree with you about discuss this own feature. I have a master_jsr310 branch in my own forked repo to evaluate it.

Regards,
Antonio.

@neroux
Copy link
Contributor

neroux commented Mar 11, 2023

I guess the best way will be to verify as mentioned at #637 (comment). Maybe you can check the date libraries as well, as there may be also compatibility issues.

@rometools rometools locked and limited conversation to collaborators Mar 11, 2023
@PatrickGotthard PatrickGotthard converted this issue into discussion #641 Mar 11, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants