Re: [threeten-develop] Key Issue A: Modules/Size

[Stephen C. <sco...@jo...>]

On 17 October 2012 06:13, Meno Hochschild <mho...@gm...> wrote:
> My problem of understanding of presented option D is following: What
> does class splitting mean here? Until now I thought jigsaw is about
> splitting packages along module boundaries without moving classes
> between packages. Here it seems to me we might get modified classes like
> LocalDate without its nice getters (like getYear() etc.) or
> plusXYZ()/minusXYZ()-Methods as JSR310 embedded subset. So when these
> methods are to be removed where shall we find these methods again after
> "class splitting"? New classes in a server-side module as decorators of
> SimplifiedLocalDate...?

This is a theoretical language feature. While there is no current sign
of Oracle working on such a concept, I have checked and recieved a
verbal indication from a key person that such a feature is not
unrealistic. No-one should take that as any kind of suggestion that
Oracle will go in that direction, as clearly class-splitting is a
complex and tricky feature.

In practical terms, I would expect the class LocalDate to have one set
of methods in the embedded environment and the full set of methods in
the non-embedded environment. We can all imagine possible syntax
tricks for this, so lets not do so (as its not relevant here).

What is relevant is whether Oracle wish to have the debate internally
(driven by 310 needs) to argue for this feature, or whether one of the
other options would be preferred.

@Israel, for JDK8, option D would probably require documenting the set
of methods that might be removed in a future embedded module-based
release. (There is no guarantee that the JDK8 embedded profile will
match the JDK9 modularised embedded profile AFAICT).

Stephen