Java EE (Java Enterprise Edition) General Discussion

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Who's Adopting JSRs?

kariannaOct 5 2015 — edited Mar 20 2017

The Grids below indicate which JUGs, individuals and organisations are working (or have worked on) JSRs.

**NOTE: Multiple JUGs, individuals and organisations can and should collaborate on a particular JSR!** There's always plenty of work to do and it can be easily distributed.

Overall List

**36** separate JUGs have already joined!

Belgium JUG, Bucharest JUG, Campinas JUG, CEJUG, Chennai JUG, Chicago JUG, CLOJUG, Cologne JUG, Congo JUG, Detroit JUG, EGJUG, Faso JUG, Guadalajara JUG, GUJavaSC, Houston JUG, Hyderabad JUG, Indonesia JUG, Istanbul JUG, Japan JUG, Java Hellenic User Group, Joglo Semar JUG, Jozi JUG, London Java Community (LJC), Madras JUG, Madrid JUG, MBale JUG, Medellin JUG, Morocco JUG, Netherlands JUG, Peru JUG, Philadelphia JUG, PT.JUG, Silicon Valley JUG, SouJava JUG, Toronto JUG, Ukraine JUG, .

JSRs in progress

These JSRs are currently going through the Java Community Process (JCP) in order to become a ratified standard.

It's a great time to get involved in these early to help shape the future!

<= #340

| JUG/Individual/
Organisation | JSR 362
(Portlet 3.0) | JSR 363
(Units of Measurement) | JSR 365
(CDI 2.0) | JSR 366
(Java EE 8) | JSR 367
(JSON-B) | JSR 368
(JMS 2.1) | JSR 369
(Servlet 4.0) |
| CJUG | | | | JSR 366 | | | |
| Chennai JUG | | JSR 363 | | | | | |
| EGJUG | | JSR 363 | | JSR 366 | JSR 367 | JSR 368 | |
| FASOJUG | | | | | JSR 367 | | |
| Guadalajara JUG | | | | | JSR 367 | | |
| GUJavaSC | | | JSR 365 | | | | JSR 369 |
| Hyderabad JUG | | JSR 363 | | | | | |
| Java Hellenic User Group - JHUG | | | | JSR 366 | | | |
| LJC | | JSR 363 | JSR 365 | JSR 366 | JSR 367 | JSR 368 | |
| MoroccoJUG | | JSR 363 | JSR 365 | | JSR 367 | | JSR 369 |
| Peru JUG | | | | JSR 366 | JSR 367 | | JSR 369 |
| Philly JUG | | | | JSR 366 | | JSR 368 | JSR 369 |
| SouJava | | JSR 363 | | | | | |
| Ukraine JUG | | | | | JSR 367 | | |

>= #370

JSR 373

(Java EE
Mgmt 2.0)

JSR 374

(JSONP 1.1)

JSR 375

(Java EE
Security)

JSR 376

(Jigsaw)

JSR 377

(Desktop / Embedded
API

JSR 378

(Portlet 3.0 Bridge

for JSF 2.0)

JSR 379

(Java 9)

JSR 380

(Bean Validation 2.0)

|
| Bucharest JUG | | | | | JSR 374 | | | | | | |
| Detroit JUG | | | | | | | | | | JSR 379 | |
| EGJUG | | JSR 371 | JSR 372 | | | | | | | | |
| Guadalajara JUG | JSR 370 | | | | | | | | | | |
| GUJavaSC | JSR 370 | JSR 371 | | | | | | | | | |
| Japan Java User Group - JJUG | | JSR 371 | | | | | | | | | |
| Java Hellenic User Group - JHUG | | JSR 371 | | | | | | | | | |
| LJC | JSR 370 | JSR 371 | | | | | | | | JSR 379 | |
| Madras JUG | | | | | JSR 374 | | | | | | |
| Medellin JUG | | | | | | | | | | | JSR 380 |
| MoroccoJUG | JSR 370 | JSR 371 | | | | | | | | | |
| Netherlands JUG | | JSR 371 | | | | | | | | JSR 379 | |
| Peru JUG | | JSR 371 | | | JSR 374 | JSR 375 | | | | JSR 379 | |
| Philly JUG | | | | | | JSR 375 | | | | JSR 379 | |

Live JSRs

See - These JSRs are now ratified standards - but there's plenty you can still help with such as educational efforts, working on implementations, helping with the next revision etc.

Closed JSRs

See

A Note for Spec Leads / EG members

It's very important that any Adopt a JSR efforts are coordinated with with the Spec Leads / EG!

The best way to call for volunteers is to mail the [adopt-a-jsr@googlegroups.com members list]. After that, each JUG, individual or organisation in the 'Who Is Adopting JSRs' matrix should ideally join the existing mailing lists etc that the JSR already has in place to co-ordinate work. We've made some suggestions (see What to work on for JSR) as to what work an Adopt a JSR group can work on, but would love to hear more ideas!

Dude!

Answer

Yes. Each database will require its own SGA segment and additional databases will add too the total size required. POSIX or /dev/shm shared memory is similar to a RAM disk, which maps memory to virtual files to be shared among processes. By default, the maximum size of /dev/shm is 50 % of the physical or installed RAM. It does however not reserve or allocate RAM other than what is actually being used.

Keep in mind that Oracle database AMM and /dev/shm are not recommended for large memory configurations. As I recall, if your SGA is greater than 2 GB, you should use kernel hugepages instead. Kernel hugepages are more efficient due to larger memory pages, which requires far less resources for memory management and results in much better performance.

An Oracle database instance can use SYS V shared memory, which is either kernel hugepages or conventional 4k memory pages, but cannot use POSIX /dev/shm for SGA and SYS V at the same time. You can however use different shared memory concepts for different Oracle database instances on the same server. For example, running an +ASM instance using AMM and another Oracle database using kernel hugepages and ASMM.

Speaking of shared memory, the SHMMAX kernel parameter applies to SYS V shared memory only. It's a safeguard parameter to limit how much shared memory a process can possibly use and needs to be large enough to fit the largest SGA of any of your Oracle databases. SHMMAX for a server that runs Oracle database is typically set to 4 TB or whatever the platform being x86 or x64 theoretically supports. SHMMAX does not apply to POSIX /dev/shm and Oracle AMM.

For more info, see the following:

https://docs.oracle.com/cd/E11882_01/server.112/e10839/appi_vlm.htm#UNXAR385

Btw, if you have to use OS release 5, use 5.11 at least. There is no reason to run 5.6, which is obsolete.

Marked as Answer by Jhil · Sep 27 2020

1 - 1

Added on Oct 5 2015

#adopt-a-jsr, #consolidate-jcp, #legacy-documents

0 comments

1,829 views