Remove Java dependencies from uhabits-core

[iSoron]

Description

In previous refactorings, we moved most of the application code from uhabits-android (a module with dependencies to Android classes) to uhabits-core (a Java module without any Android dependencies). While this made the application more portable and much faster to test, it is still not sufficient to make it run on iOS or the web. To leverage Kotlin Multiplatform, we need to remove all dependencies not only to Android, but also to Java classes! For example, any Kotlin classes that import java.util or java.math cannot be reused in other platforms.

This task is to remove Java dependencies from as many classes in uhabits-core as possible.

Notes

1. As we remove Java dependencies, we should move the classes from uhabits-core/src/jvmMain to uhabits-core/src/commonMain. This will also prevent Java dependencies from being accidentally reintroduced in future code changes.
2. Many classes currently depend (directly or indirectly) on java.util.Calendar and java.util.Date. These classes should switch to org.isoron.platform.time.LocalDate, a pure-Kotlin implementation.
3. We already have multiplatform database support in uhabits-core-legacy. In includes an abstract Database class, as well as concrete iOS, JavaScript and JVM implementations. This code needs to be ported to uhabits-core and the current database/*.kt files need to be removed.
4. File operations should rely on the abstract classes in org.isoron.platform.io.Files. We already have concrete iOS, JavaScript and JVM implementations for these classes in uhabits-core-legacy.
5. I believe javax.inject annotations are fine, and can be kept, but we should double check.

Subtasks

Deprecated

The files below should be removed, and replaced by existing implementations (see notes above):

• database/Cursor.kt
• database/Database.kt
• database/DatabaseOpener.kt
• database/JdbcCursor.kt
• database/JdbcDatabase.kt
• database/MigrationHelper.kt
• database/Repository.kt
• database/SQLParser.kt
• models/Timestamp.kt

Direct dependencies to java.*

The files below need to be modified, and all references to java.* classes should be replaced by existing Kotlin classes, or by new pure-Kotlin implementations:

• commands/CommandRunner.kt
• io/AbstractImporter.kt
• io/GenericImporter.kt
• io/HabitBullCSVImporter.kt
• io/HabitsCSVExporter.kt
• io/LoopDBImporter.kt
• io/RewireDBImporter.kt
• io/TickmateDBImporter.kt
• models/EntryList.kt
• models/Habit.kt
• models/HabitList.kt
• models/HabitType.kt
• models/memory/MemoryHabitList.kt
• models/ModelObservable.kt
• models/NumericalHabitType.kt
• models/ScoreList.kt
• models/sqlite/records/HabitRecord.kt
• models/Streak.kt
• models/WeekdayList.kt
• preferences/Preferences.kt
• preferences/PropertiesStorage.kt
• reminders/ReminderScheduler.kt
• tasks/ExportCSVTaskFactory.kt
• tasks/ExportCSVTask.kt
• tasks/SingleThreadTaskRunner.kt
• ui/NotificationTray.kt
• ui/screens/habits/list/HabitCardListCache.kt
• ui/screens/habits/list/ListHabitsBehavior.kt
• ui/screens/habits/show/ShowHabitMenuPresenter.kt
• ui/screens/habits/show/views/FrequencyCard.kt
• ui/screens/habits/show/views/TargetCard.kt
• ui/views/NumberButton.kt
• ui/views/Ring.kt
• utils/DateFormats.kt
• utils/DateUtils.kt
• utils/FileExtensions.kt
• utils/MidnightTimer.kt
• utils/StringUtils.kt

No direct dependencies to java.*

The files below need to be moved to commonMain. While they don't have any direct references to java.* classes, they may still indirectly depend on these classes.

• AppScope.kt
• commands/ArchiveHabitsCommand.kt
• commands/ChangeHabitColorCommand.kt
• commands/Command.kt
• commands/CreateHabitCommand.kt
• commands/CreateRepetitionCommand.kt
• commands/DeleteHabitsCommand.kt
• commands/EditHabitCommand.kt
• commands/UnarchiveHabitsCommand.kt
• Constants.kt
• database/Column.kt
• database/Table.kt
• database/UnsupportedDatabaseVersionException.kt
• io/Logging.kt
• models/Entry.kt
• models/Frequency.kt
• models/HabitMatcherBuilder.kt
• models/HabitMatcher.kt
• models/HabitNotFoundException.kt
• models/memory/MemoryModelFactory.kt
• models/ModelFactory.kt
• models/PaletteColor.kt
• models/Reminder.kt
• models/Score.kt
• models/sqlite/records/EntryRecord.kt
• models/sqlite/SQLiteEntryList.kt
• models/sqlite/SQLiteHabitList.kt
• models/sqlite/SQLModelFactory.kt
• models/StreakList.kt
• preferences/WidgetPreferences.kt
• tasks/Task.kt
• tasks/TaskRunner.kt
• test/HabitFixtures.kt
• ui/callbacks/OnColorPickedCallback.kt
• ui/callbacks/OnConfirmedCallback.kt
• ui/callbacks/OnFinishedCallback.kt
• ui/callbacks/OnToggleCheckmarkListener.kt
• ui/screens/habits/list/HintListFactory.kt
• ui/screens/habits/list/HintList.kt
• ui/screens/habits/list/ListHabitsMenuBehavior.kt
• ui/screens/habits/list/ListHabitsSelectionMenuBehavior.kt
• ui/screens/habits/show/ShowHabit.kt
• ui/screens/habits/show/views/BarCard.kt
• ui/screens/habits/show/views/HistoryCard.kt
• ui/screens/habits/show/views/NotesCard.kt
• ui/screens/habits/show/views/OverviewCard.kt
• ui/screens/habits/show/views/ScoreCard.kt
• ui/screens/habits/show/views/StreakCart.kt
• ui/screens/habits/show/views/SubtitleCard.kt
• ui/ThemeSwitcher.kt
• ui/views/BarChart.kt
• ui/views/CheckmarkButton.kt
• ui/views/HabitListHeader.kt
• ui/views/HistoryChart.kt
• ui/views/Themes.kt
• ui/widgets/WidgetBehavior.kt

[sgallese]

Interesting seeing the work done in core-legacy.

Is there a reason to prefer a DIY LocalDate vs using a multiplatform library like kotlinx-datetime?

Same question for:
ResourceFile vs kotlinx-io
Database vs SQLDelight

All for common abstractions, but for these lower level libraries, would it be a better developer experience to leverage community driven multiplatform projects and their well-thought-out APIs?

[iSoron]

Is there a reason to prefer a DIY LocalDate vs using a multiplatform library like kotlinx-datetime?

I am not sure kotlinx-datetime was available when LocalDate was first implemented. Since it's already implemented, I would like to keep it. We can replace it later if it proves necessary.

ResourceFile vs kotlinx-io

If kotlinx-io can be used to simplify the implementation of ResourceFile and UserFile, we can use it.

Database vs SQLDelight

I am deliberately avoiding high-level APIs or wrappers for SQL. We went through a couple of these libraries since the app was first released, and there have always been subtle issues.