Java 12 - nowe funkcje

Java 12 - nowe funkcje
Bulldogjob
  • Rejestracja:prawie 7 lat
  • Ostatnio:ponad 5 lat
  • Postów:31
1

Dzisiaj Java 12 wejdzie w fazę General Availability. Po wielu nowościach, dostarczonych wraz z Javą 11, tym razem mamy do czynienia z nieco skromniejszym wydaniem, które nie jest LTS-em. Zobaczmy, co oferuje programistom ta wersja Javy.

Wyrażenie Switch
Chyba najgorętsza nowość, o której mówi się w internecie. Switch od teraz jest już wyrażeniem. Oprócz tego pojawiła się nowa składnia, z której można skorzystać w trybie preview (dzięki przełącznikowi --enable-preview).

Od tej pory archiwum class data-sharing (CDS) będzie generowane automatycznie.
Zapewnia to JEP 341. CDS pomaga w szybszym starcie aplikacji. Dla HelloWorld to aż 32%. Jest więc o co grać, dlatego w czasie kompilacji z automatu zostanie dodane archiwum z CDS do wyprodukowanego obrazu.

Więcej nowości opisał Adam (dobry człowiek) tutaj: https://bulldogjob.pl/news/545-java-12-nowe-funkcje

nie100sowny
Przynajmniej mają dobry timing.
Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 8 godzin
1

No to teraz w Javie mamy dwa GC z niskimi opóźnieniami:

ZTCW to jednak Shenandoah jest wycięty z buildów przygotowanych przez Oracle'a i trzeba poczekać, aż pełne buildy OpenJDK pojawią się np na https://adoptopenjdk.net/ albo w jakichś innych repozytoriach. Sprawdzę później :)


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit
WhiteLightning
  • Rejestracja:prawie 14 lat
  • Ostatnio:5 dni
  • Postów:3168
0

@Wibowit: warto dodacze z tymi GC to cos za cos: mamy krotkie opoznienia, ale spada przepustowosc.

Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 8 godzin
0

Według slajdów Oracle'a przepustowość pod ZGC jest tylko kilka procent gorsza niż pod G1. Zależy co jest większym problemem w danym przypadku: duże przestoje co jakiś czas czy trochę mniejsza ogólna przepustowość. Teraz to przynajmniej w Javie jest wybór, bo dla przykładu w Go ( https://golang.org/ ) jest nacisk tylko i wyłącznie na zmniejszanie pauzy GC, kosztem zarówno przepustowości jak i narzutu pamięciowego: https://blog.golang.org/ismmkeynote


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit
Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 8 godzin
0

Przetestowałem Javę 12 i Go w benchmarku binarytrees, gdyż jest on dość pesymistycznym przypadkiem jeśli chodzi o automatyczne odśmiecanie.

Na początek wersje:

Wersje oprogramowania:

Kopiuj
$ lsb_release -a
LSB Version:	core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.6 LTS
Release:	16.04
Codename:	xenial
$ go version
go version go1.6.2 linux/amd64
$ ~/devel/jdk-12/bin/java -version
openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)

Wyniki wydajności:

Kopiuj
 time ./binarytrees.go-5.go_run 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m14.385s
user	0m54.290s
sys	0m0.254s
$ time ~/devel/jdk-12/bin/java binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m2.425s
user	0m7.081s
sys	0m0.726s
$ time ~/devel/jdk-12/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m4.068s
user	0m8.820s
sys	0m3.112s

Jak widać Go radzi sobie bardzo słabo. Trzeba jednak wziąć pod uwagę iż ZGC zaalokował sobie sporo pamięci u mnie. Co się stanie jak dam w Javie mniejszą stertę?

G1 GC zachowuje się praktycznie tak samo:

Kopiuj
$ time ~/devel/jdk-12/bin/java binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m2.425s
user	0m7.081s
sys	0m0.726s
$ time ~/devel/jdk-12/bin/java -Xmx2g binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m2.402s
user	0m7.495s
sys	0m0.353s
$ time ~/devel/jdk-12/bin/java -Xmx1g binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m2.465s
user	0m7.857s
sys	0m0.222s

ZGC natomiast sporo zwalnia, ale i tak jest dużo szybsze od Go:

Kopiuj
$ time ~/devel/jdk-12/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m4.068s
user	0m8.820s
sys	0m3.112s
$ time ~/devel/jdk-12/bin/java -Xmx2g -XX:+UnlockExperimentalVMOptions -XX:+UseZGC binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m4.879s
user	0m11.839s
sys	0m1.076s
$ time ~/devel/jdk-12/bin/java -Xmx1g -XX:+UnlockExperimentalVMOptions -XX:+UseZGC binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m7.458s
user	0m15.141s
sys	0m0.562s

Jeśli dalej przytniemy stertę to ZGC już zwalnia prawie do poziomu Go, chociaż G1 GC nadal utrzymuje wysoką przepustowość:

Kopiuj
$ time ~/devel/jdk-12/bin/java -Xmx500m binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m3.144s
user	0m9.816s
sys	0m0.197s
$ time ~/devel/jdk-12/bin/java -Xmx500m -XX:+UnlockExperimentalVMOptions -XX:+UseZGC binarytrees 21
stretch tree of depth 22	 check: 8388607
2097152	 trees of depth 4	 check: 65011712
524288	 trees of depth 6	 check: 66584576
131072	 trees of depth 8	 check: 66977792
32768	 trees of depth 10	 check: 67076096
8192	 trees of depth 12	 check: 67100672
2048	 trees of depth 14	 check: 67106816
512	 trees of depth 16	 check: 67108352
128	 trees of depth 18	 check: 67108736
32	 trees of depth 20	 check: 67108832
long lived tree of depth 21	 check: 4194303

real	0m13.543s
user	0m23.298s
sys	0m0.305s

Dalsze przycinanie byłoby już chyba trochę nie do końca sensowne, bo obiekty w Javie mają raczej trochę większy narzut pamięciowy niż obiekty w Go, a samo ZGC nie jest przygotowane do małych stert.

Shenandoah nie jest dostępne w buildzie od Oracle'a, czyil w buildzie pod adresem: http://jdk.java.net/12/

Kopiuj
$ time ~/devel/jdk-12/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC binarytrees 21
Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported

real	0m0.005s
user	0m0.000s
sys	0m0.005s

"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit
TurkucPodjadek
TurkucPodjadek
  • Rejestracja:około 8 lat
  • Ostatnio:około 4 lata
  • Postów:607
0

@Wibowit: ten benchmark do Go z BT jest totalnie z czterech liter, bo nie używa się tam sync.Pool, którego masz w standardowej bibliotece dostępnego (za to w niektórych innych językach custom allocatory są używane jakoś bez przeszkód). Zresztą, tam prawie każdy "benchmark" jest totalnie oderwany od rzeczywistości. Po prostu nikt ogarnięty tego BT tak w Go nie napisze.

Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 8 godzin
0

W tych benchmarkach chodzi o sposób osiągnięcia celu, a nie o cel sam w sobie. Gdyby chodziło tylko o wypisany wynik, to benchmark binarytrees można by załatwić kilkoma printfami.

Wiem, że niektóre implementacje stosują pule, a niektóre nie. Łatwo to jednak wyczaić - wystarczy zajrzeć do kodu i poszukać jakiegoś "include pool".

Przy domyślnych ustawieniach i bez użycia pul, alokacja i odśmiecanie w Javie jest 2x szybsze niż new/delete w C++ i 8x szybsze niż alokacja i odśmiecanie w Go. Takie coś miał testować ten benchmark.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
TurkucPodjadek
TurkucPodjadek
  • Rejestracja:około 8 lat
  • Ostatnio:około 4 lata
  • Postów:607
0
Wibowit napisał(a):

W tych benchmarkach chodzi o sposób osiągnięcia celu, a nie o cel sam w sobie. Gdyby chodziło tylko o wypisany wynik, to benchmark binarytrees można by załatwić kilkoma printfami.

Wiem, że niektóre implementacje stosują pule, a niektóre nie. Łatwo to jednak wyczaić - wystarczy zajrzeć do kodu i poszukać jakiegoś "include pool".

Przy domyślnych ustawieniach i bez użycia pul, alokacja i odśmiecanie w Javie jest 2x szybsze niż new/delete w C++ i 8x szybsze niż alokacja i odśmiecanie w Go. Takie coś miał testować ten benchmark.

Tak, o tym właśnie mówię. Sposób osiągnięcia celu w Go jest dziwny. Nikt tak tego nie pisze. Za to jak autor tejże strony pisze, że to tylko zabawa i w takich ramach, zabawy właśnie, bym te benchmarki traktował. Czyli nic, co ma jakieś miarodajne przełożenie na cokolwiek. Można wyprodukować dowolnie wolny kod np. w C++, a superszybki w jakimś slamazarnym języku i taki kod C++, mimo iż będzie pisany w erze paleozoicznej C++, to go przyjmą, bo to tylko zabawa.

Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 8 godzin
0

Mnie interesuje wydajność generycznych mechanizmów do zarządzania pamięcią, a nie pule, których mało kto używa, bo nadają się tylko do specyficznych zastosowań. Pule widziałem tylko i wyłącznie w benchmarkach. Jeśli interesuje cię wydajność pul to może podeślij rozwiązanie oparte na pulach? Mnie to i tak zupełnie nie obchodzi :]

Pokaż mi jakiś otwartoźródłowy projekt w Go, w którym pule są szeroko wykorzystywane. Zobaczymy na ile to wykorzystanie pul jest miarodajne.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit
TurkucPodjadek
TurkucPodjadek
  • Rejestracja:około 8 lat
  • Ostatnio:około 4 lata
  • Postów:607
0
Wibowit napisał(a):

Mnie interesuje wydajność generycznych mechanizmów do zarządzania pamięcią, a nie pule, których mało kto używa, bo nadają się tylko do specyficznych zastosowań. Pule widziałem tylko i wyłącznie w benchmarkach. Jeśli interesuje cię wydajność pul to może podeślij rozwiązanie oparte na pulach? Mnie to i tak zupełnie nie obchodzi :]

W tym właśnie problem, Ci mówię, że tak się w Go nie robi + inni pisali już bez puli BT i osiągali lepsze czasy (stdlib), dlatego ten "benchmark" nie jest zupełnie miarodajny w Go (nie wiem jak w innych językach - słyszałem podobne opinie)

Pokaż mi jakiś otwartoźródłowy projekt w Go, w którym pule są szeroko wykorzystywane. Zobaczymy na ile to wykorzystanie pul jest miarodajne.

Grep w moim GOPATH zwraca mi za dużo wyników (dokładnie tysiąc), więc podam Ci ostatni z listy: zerolog.

Wibowit
  • Rejestracja:prawie 20 lat
  • Ostatnio:około 8 godzin
0

W tym właśnie problem, Ci mówię, że tak się w Go nie robi + inni pisali już bez puli BT i osiągali lepsze czasy (stdlib), dlatego ten "benchmark" nie jest zupełnie miarodajny w Go (nie wiem jak w innych językach - słyszałem podobne opinie)

Jeśli chcę porównać narzut na read barrier, write barrier i ogólnie na tracing GC to wykorzystanie puli mi w tym tylko i wyłącznie przeszkodzi.

Grep w moim GOPATH zwraca mi za dużo wyników (dokładnie tysiąc), więc podam Ci ostatni z listy: zerolog.

Biblioteka do logowania to raczej nie jest duży projekt. W Javce też są tego typu loggery (w sensie bez śmiecenia w pamięci):
https://logging.apache.org/log4j/2.x/manual/garbagefree.html
https://logging.apache.org/log4j/2.x/manual/async.html

Z tego co widzę na https://golang.org/src/sync/pool.go te pule w Go to wcale nie mają jakiegoś ręcznego reseta (jak te w C/C++) a służą raczej do odśmiecania podczas pauzy GC (WTF? przecież w Go wykonali masę roboty, by pauzy były jak najkrótsze) - widać to w komentarzu wewnątrz funkcji poolCleanup().

Ponadto w benchmarks game jest jedno rozwiązanie, które wykorzystuje sync.Pool i, uwaga, jest najwolniejsze, kilka razy wolniejsze od najszybszego!
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html
Najszybsze rozwiązanie w Go: Go #5 - 26.94s
Jedyne rozwiązanie korzystające z sync.Pool: Go #6 - 123.44s


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 1x, ostatnio: Wibowit
SL
  • Rejestracja:około 7 lat
  • Ostatnio:około 2 godziny
  • Postów:862
0

@TurkucPodjadek Nie rozumiem jak sync.Pool mógłby coś pomóc w wynikach: ten problem jest nastawiony na jak największy throughput, a nie latency. Dodanie czy wyciągnięcie zasobu z tej puli jest bardzo skomplikowane (można podejrzeć https://golang.org/src/sync/pool.go?s=1633:1992#L88) w porównianiu do Javowego modelu alokacji typu bump pointer (przynajmniej dla G1, nie wiem jak to robi ZGC). To, że alokacja pamięci/GC w golang nie wyrabiają w tego typu problemach to tylko wina języka/platformy.

Kliknij, aby dodać treść...

Pomoc 1.18.8

Typografia

Edytor obsługuje składnie Markdown, w której pojedynczy akcent *kursywa* oraz _kursywa_ to pochylenie. Z kolei podwójny akcent **pogrubienie** oraz __pogrubienie__ to pogrubienie. Dodanie znaczników ~~strike~~ to przekreślenie.

Możesz dodać formatowanie komendami , , oraz .

Ponieważ dekoracja podkreślenia jest przeznaczona na linki, markdown nie zawiera specjalnej składni dla podkreślenia. Dlatego by dodać podkreślenie, użyj <u>underline</u>.

Komendy formatujące reagują na skróty klawiszowe: Ctrl+B, Ctrl+I, Ctrl+U oraz Ctrl+S.

Linki

By dodać link w edytorze użyj komendy lub użyj składni [title](link). URL umieszczony w linku lub nawet URL umieszczony bezpośrednio w tekście będzie aktywny i klikalny.

Jeżeli chcesz, możesz samodzielnie dodać link: <a href="link">title</a>.

Wewnętrzne odnośniki

Możesz umieścić odnośnik do wewnętrznej podstrony, używając następującej składni: [[Delphi/Kompendium]] lub [[Delphi/Kompendium|kliknij, aby przejść do kompendium]]. Odnośniki mogą prowadzić do Forum 4programmers.net lub np. do Kompendium.

Wspomnienia użytkowników

By wspomnieć użytkownika forum, wpisz w formularzu znak @. Zobaczysz okienko samouzupełniające nazwy użytkowników. Samouzupełnienie dobierze odpowiedni format wspomnienia, zależnie od tego czy w nazwie użytkownika znajduje się spacja.

Znaczniki HTML

Dozwolone jest używanie niektórych znaczników HTML: <a>, <b>, <i>, <kbd>, <del>, <strong>, <dfn>, <pre>, <blockquote>, <hr/>, <sub>, <sup> oraz <img/>.

Skróty klawiszowe

Dodaj kombinację klawiszy komendą notacji klawiszy lub skrótem klawiszowym Alt+K.

Reprezentuj kombinacje klawiszowe używając taga <kbd>. Oddziel od siebie klawisze znakiem plus, np <kbd>Alt+Tab</kbd>.

Indeks górny oraz dolny

Przykład: wpisując H<sub>2</sub>O i m<sup>2</sup> otrzymasz: H2O i m2.

Składnia Tex

By precyzyjnie wyrazić działanie matematyczne, użyj składni Tex.

<tex>arcctg(x) = argtan(\frac{1}{x}) = arcsin(\frac{1}{\sqrt{1+x^2}})</tex>

Kod źródłowy

Krótkie fragmenty kodu

Wszelkie jednolinijkowe instrukcje języka programowania powinny być zawarte pomiędzy obróconymi apostrofami: `kod instrukcji` lub ``console.log(`string`);``.

Kod wielolinijkowy

Dodaj fragment kodu komendą . Fragmenty kodu zajmujące całą lub więcej linijek powinny być umieszczone w wielolinijkowym fragmencie kodu. Znaczniki ``` lub ~~~ umożliwiają kolorowanie różnych języków programowania. Możemy nadać nazwę języka programowania używając auto-uzupełnienia, kod został pokolorowany używając konkretnych ustawień kolorowania składni:

```javascript
document.write('Hello World');
```

Możesz zaznaczyć również już wklejony kod w edytorze, i użyć komendy  by zamienić go w kod. Użyj kombinacji Ctrl+`, by dodać fragment kodu bez oznaczników języka.

Tabelki

Dodaj przykładową tabelkę używając komendy . Przykładowa tabelka składa się z dwóch kolumn, nagłówka i jednego wiersza.

Wygeneruj tabelkę na podstawie szablonu. Oddziel komórki separatorem ; lub |, a następnie zaznacz szablonu.

nazwisko;dziedzina;odkrycie
Pitagoras;mathematics;Pythagorean Theorem
Albert Einstein;physics;General Relativity
Marie Curie, Pierre Curie;chemistry;Radium, Polonium

Użyj komendy by zamienić zaznaczony szablon na tabelkę Markdown.

Lista uporządkowana i nieuporządkowana

Możliwe jest tworzenie listy numerowanych oraz wypunktowanych. Wystarczy, że pierwszym znakiem linii będzie * lub - dla listy nieuporządkowanej oraz 1. dla listy uporządkowanej.

Użyj komendy by dodać listę uporządkowaną.

1. Lista numerowana
2. Lista numerowana

Użyj komendy by dodać listę nieuporządkowaną.

* Lista wypunktowana
* Lista wypunktowana
** Lista wypunktowana (drugi poziom)

Składnia Markdown

Edytor obsługuje składnię Markdown, która składa się ze znaków specjalnych. Dostępne komendy, jak formatowanie , dodanie tabelki lub fragmentu kodu są w pewnym sensie świadome otaczającej jej składni, i postarają się unikać uszkodzenia jej.

Dla przykładu, używając tylko dostępnych komend, nie możemy dodać formatowania pogrubienia do kodu wielolinijkowego, albo dodać listy do tabelki - mogłoby to doprowadzić do uszkodzenia składni.

W pewnych odosobnionych przypadkach brak nowej linii przed elementami markdown również mógłby uszkodzić składnie, dlatego edytor dodaje brakujące nowe linie. Dla przykładu, dodanie formatowania pochylenia zaraz po tabelce, mogłoby zostać błędne zinterpretowane, więc edytor doda oddzielającą nową linię pomiędzy tabelką, a pochyleniem.

Skróty klawiszowe

Skróty formatujące, kiedy w edytorze znajduje się pojedynczy kursor, wstawiają sformatowany tekst przykładowy. Jeśli w edytorze znajduje się zaznaczenie (słowo, linijka, paragraf), wtedy zaznaczenie zostaje sformatowane.

  • Ctrl+B - dodaj pogrubienie lub pogrub zaznaczenie
  • Ctrl+I - dodaj pochylenie lub pochyl zaznaczenie
  • Ctrl+U - dodaj podkreślenie lub podkreśl zaznaczenie
  • Ctrl+S - dodaj przekreślenie lub przekreśl zaznaczenie

Notacja Klawiszy

  • Alt+K - dodaj notację klawiszy

Fragment kodu bez oznacznika

  • Alt+C - dodaj pusty fragment kodu

Skróty operujące na kodzie i linijkach:

  • Alt+L - zaznaczenie całej linii
  • Alt+, Alt+ - przeniesienie linijki w której znajduje się kursor w górę/dół.
  • Tab/⌘+] - dodaj wcięcie (wcięcie w prawo)
  • Shit+Tab/⌘+[ - usunięcie wcięcia (wycięcie w lewo)

Dodawanie postów:

  • Ctrl+Enter - dodaj post
  • ⌘+Enter - dodaj post (MacOS)