Supporting Java™ 9 in Eclipse - A critical perspective - Stephan Herrmann

Stephan Herrmann
Supporting Java™ 9 in Eclipse
—
A critical perspective
J
D
T
Simply Retail.

2
J
D
T
Stephan Herrmann @Eclipse Day India 2018 – published under the EPL
Supporting Java™ 9 in Eclipse
A Play in 4 Acts

3
J
D
T
Act 1
What is Jigsaw all about?
That's simple and easy!That's simple and easy!

4
J
D
T
Simple: Module Syntax vs. OSGi Manifest
module org.m1 { …
requires org.m2;
requires transitive org.m3;
exports org.pack1;
exports org.pack2 to org.m2;
provides org.Ifc with org.Impl;
uses org.Ifc;
Bundle-SymbolicName: org.m1
Require-Bundle: org.m2
org.m3;visibility:=reexport
Export-Package: org.pack1
org.pack2;x-friends=”org.m2”
service.xml
module-info.java MANIFEST.MF
<scr:component
xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"
name="IMyService">
<implementation class="org.Impl"/>
<service>
<provide interface="org.Ifc"/>
</service>
</scr:component>

5
J
D
T
Act 1: That's simple and easy!
DEMO: Modules in Eclipse

6
J
D
T
Act 2
A closer look at module-info
–
from a tool smith's perspective
Expect a slight
sense of surprise
Expect a slight
sense of surprise

8
J
D
T
Act 2: Something's weird
JDT API (1):
org.eclipse.jdt.core.ToolFactory.createScanner(..)
org.eclipse.jdt.core.compiler.IScanner
●
void resetTo(int startPosition, int endPosition)
●
int getNextToken()
org.eclipse.jdt.core.compiler.ITerminalSymbols.TokenNameIdentifer
In Java 9 this API is beyond repair
restricted keywords:
●
“keywords that are keywords when they are keywords, else identifers” [my words]
●
classifcation keyword / identifer happens after parsing
should we remove this API (and break all clients of JDT)?
just hope that nobody will use it for module-info.java?

9
J
D
T
JDT API (1):
org.eclipse.jdt.core.ToolFactory.createScanner(..)
org.eclipse.jdt.core.compiler.IScanner
●
void resetTo(int startPosition, int endPosition)
●
int getNextToken()
org.eclipse.jdt.core.compiler.ITerminalSymbols.TokenNameIdentifer
In Java 9 this API is beyond repair
restricted keywords:
●
“keywords that are keywords when they are keywords, else identifers” [my words]
●
classifcation keyword / identifer happens after parsing
should we remove this API (and break all clients of JDT)?
just hope that nobody will use it for module-info.java?
import to.uses;
import to.module;
import to.to;
module module {
requires requires;
exports to to exports;
uses module;
provides uses with to;
requires transitive transitive;
}
import to.uses;
import to.module;
import to.to;
module module {
requires requires;
exports to to exports;
uses module;
provides uses with to;
requires transitive transitive;
}

11
J
D
T
Updating Tools Java™ 8 Java→ ™ 9
cannot be done in a compatible way

12
J
D
T
Act 3
There is complexity
—
Questions:
What is the meaning of a.b.C1?
Is the reference a.b.C1 legal?
Does Java 9 support split packages?

14
J
D
T
Act 3: Concepts
How we want to see the world:
Module 1
package a
C1 C2C0
package a.b
C1 C3
Module 2
package a.c
C1 C2
package a.b
C1 C4
requires

15
J
D
T
Act 3: Realization
This is the world according to JLS:
Module 1 Module 2
C1
CU1
C0
associated with
CU2
C2
package a
declares
package bis member
within
CU1
C1
CU1
C1
package c
CU2
C2
requires
exports

16
J
D
T
Act 3: unnecessary complexity
Containment
module
package
class
Independent
packages among each other
Module 1
package a
C1 C2C0
package a.b
C1 C3
Module 2
package a.c
C1 C2
package a.b
C1 C4
requires
Emulation by indirect relations
cu is associated to module
cu declares package
cu contains class
Containment
package
sub-package
Mod-
ule 1
Mod-
ule 2C1
C0
CU1
C2
CU2
package a
package b
C1
CU1 CU1
C1
package c
C2
CU2
requires

17
J
D
T
Act 3: Putting it to work
Inside Module2, what does a.b.C1 mean?
a.b.C1 is found in the CU1 associated with Module2
package a.b is uniquely visible from Module2
Module 1 Module 2
C1
CU1
C0CU2
C2
package a
package b
CU1
C1
CU1
C1
package c
CU2
C2
requires
package b
✔
✔
package a

18
J
D
T
Act 3: Putting it to work
Inside Module2, what does a.b.C1 mean?
package a.b is not uniquely visible, could be from Module1 or from Module2
this confguration is illegal
Module 1 Module 2
C1
CU1
C0CU2
C2
package a
package b
CU1
C1
CU1
C1
package c
CU2
C2
requires
CUX
X

19
J
D
T
Act 3: Legal but broken
Module 1 Module 2
C1
CU1
C0CU2
C2
package a
package b
CU1
C1
CU1
C1
package c
CU2
C2
requires
$ java -m Module2
Error occurred during initialization of boot layer
java.lang.LayerInstantiationException: Package a.b in both module Module1 and module Module2
$ _
Need a Layer implementation
that is capable of classloader-based isolation.
Need a Layer implementation
that is capable of classloader-based isolation.

20
J
D
T
Act 3: Legal but asking for trouble
API Leak
API mentions a type, which the client cannot mention
legal
new complexity in the implementation
put overloading and inheritance in the mix: infnite supply of new Java puzzlers
Module 1 Module 2
C1
CU1
C0CU2
C2
package a
package b
CU1
C1
CU1
C1
package c
CU2
C2
requires
public void doSomething(a.b.C1 arg) { … }public void doSomething(a.b.C1 arg) { … }

21
J
D
T
Act 3: Legal but asking for trouble
API Leak
API mentions a type, which the client cannot mention
legal
new complexity in the implementation
put overloading and inheritance in the mix: infnite supply of new Java puzzlers
Module 1 Module 2
C1
CU1
C0CU2
C2
package a
package b
CU1
C1
CU1
C1
package c
CU2
C2
requires
public void doSomething(a.b.C1 arg) { … }public void doSomething(a.b.C1 arg) { … }
Missed Opportunity
●
API leaks should be illegal
●
Or method should be unmentionable for clients
Missed Opportunity
●
API leaks should be illegal
●
Or method should be unmentionable for clients

22
J
D
T
Act 3: summary encapsulation
Split packages
concealed: legal
●
but no promise that the runtime can handle it
●
need a capable Layer implementation
merging a package (like fragment & host bundle) is illegal
●
even if no class-level confict is involved
API leaks
JLS is silent
compilers issue warnings
●
TODO: better coordinate warnings between compilers

25
J
D
T
Act 3: There is Complexity
End of Act 3
A simple surface
realized by complexity

26
J
D
T
Act 4
There's a lot more:
command line options
–illegal-access={permit,warn,debug,deny}

28
J
D
T
Act 4: Manipulating the Module Graph
Things you can change via CLI options
Add / remove / replace a module
Add a “reads” edge (“requires”)
Expose a package
●
compile time (“exports”)
●
runtime (“opens”)
Merge a module from several sources
●
patching
...

29
J
D
T
Act 4: Options
Let's map command line options
to UI

30
J
D
T
Act 4: Options
“Is modular”
Edit: enter the rabbit hole

31
J
D
T
Act 4: Options
“Is modular”
Contents
what you ask for
what you get
--limit-modules, --add-modules
default as per JEP 261

32
J
D
T
Act 4: Options
“Is modular”
Contents
what you ask for
what you get
Details
--add-exports
--add-reads (rarely needed)
--patch-module (careful!)

33
J
D
T
Act 4: Options
“Is modular”
Contents
what you ask for
what you get
Details
--add-exports
--add-reads (rarely needed)
--patch-module (careful!)
Power switch

34
J
D
T
Act 4: Options
Build vs. Run
UI should be sufcient for building
●
No need to learn cryptic CLI
Sufcient information for running?
Show Command Line
New in 2018-09

35
J
D
T
Act 4: Options
Build vs. Run
●
Show Command Line
New in 2018-09
Override Dependencies
New in Photon

36
J
D
T
Act 4: Options
Build vs. Run
●
Show Command Line
New in 2018-09
Override Dependencies
New in Photon
More UI
… work in progress ...

37
J
D
T
Epilogue
Act 4: Modifying Encapsulation?
“Gradual Encapsulation” [Herrmann 2008]
●
is encapsulation your friend or foe?
●
enforce encapsulation?
●
rules entail exceptions
Act 3: Isolation?
Separate namespace per module?
●
partly achieved / emulated
●
several opportunities missed
Act 2: Compatibility?
Java 9 is disruptive
●
against frameworks and applications
●
against tools

38
J
D
T
Epilogue
Act 4: Modifying Encapsulation?
“Gradual Encapsulation” [Herrmann 2008]
●
is encapsulation your friend or foe?
●
enforce encapsulation?
●
rules entail exceptions
Act 3: Isolation?
Separate namespace per module?
●
partly achieved / emulated
●
several opportunities missed
Act 2: Compatibility?
Java 9 is disruptive
●
against frameworks and applications
●
against tools
@NonNullByDefault
module org.eclipse.mymodule {
…
}
@NonNullByDefault
module org.eclipse.mymodule {
…
}

Supporting Java™ 9 in Eclipse - A critical perspective - Stephan Herrmann

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (10)

Similaire à Supporting Java™ 9 in Eclipse - A critical perspective - Stephan Herrmann

Similaire à Supporting Java™ 9 in Eclipse - A critical perspective - Stephan Herrmann (20)

Plus de Eclipse Day India

Plus de Eclipse Day India (20)

Dernier

Dernier (20)

Supporting Java™ 9 in Eclipse - A critical perspective - Stephan Herrmann