Talk:Java Specialists Symposium
- [View source↑]
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Disruptor pattern | 1 | 12:15, 16 October 2011 |
| JRockit JVM | 1 | 12:13, 16 October 2011 |
| Wiki venue: How about WikiEducator? | 1 | 12:03, 16 October 2011 |
The Disruptor - Concurrent Programming Framework was awarded the 2011 Duke's Choice Award. According to their Technical paper, it seems to perform faster than any other concurrent structure in the JVM (even the ArrayBlockingQueue).
The topic was proposed in the Java Specialists Symposium first day but for some reason never reached the white board.
Has any one use this pattern to provide some feedback and examples of use?
Since the acquisition of BEA by Oracle, JRockit VM became an Oracle product. After the acquisition of SUN, Oracle also inherited SUN's JVM. The latest 4.0.1 version combines the previous releases to one that includes both the Real Time VM and the Mission Control toolkit. We tried our application with the Solaris version of JRockit, both the normal and RT VM, but they both performed worse than the SUN JVM. From what we found, JRockit has not been optimized for the Solaris platform. Has anybody had any experiences with JRockit on Solaris or on other platforms? Do you actually use it in real projects?
Personally, I'd prefer to use Free and open source implementations and contribute to these (if clever enough :-).
- A related discussion I suggested previously: Software patents, Oracle, Google - implications for free software development in Java and programming in general. ... maybe next time (2012).
Pros:
- Policies in place (usage, privacy, copyright, ...)
- No need to manage a separate wiki and server (covering storage, versioning, plugins, back-ups, spam, security, privacy, etc.)
- Existing education communities may surface interested educators
- Lots of useful plugins installed and existing templates to use.
Cons:
- Not specifically a Java Specialists' site (though one can brand an area if desired)
- Heinz indicated no desire to brand the WikiEducator resource sets produced.
- Users will have to register on WikiEducator to edit pages
- Someone will have to transfer existing content (done - but some reports were not submitted - blanks)
- ideally with help from other participants (done - thanks)
- ...
Decision
Yes - do it.
- Heinz was keen to move during the event and be relieved of managing the wiki and associated issues (spam, software updates and re-configuration, screening applications to join, monitoring undesired edits, etc.) - our bright participants wont mind registering on yet another wiki and picking up from there. However, after bouncing the idea off a few participants the consensus was not to make the change in mid-stream and rather wait until after the event.
- In retrospect, I think they were right - convincing everyone to use the new one and maintaining and synchronising two wikis during the event would have been difficult (keeping one up-to-date with our dynamic space-time matrix was quite enough work :-).
- Heinz was keen to move during the event and be relieved of managing the wiki and associated issues (spam, software updates and re-configuration, screening applications to join, monitoring undesired edits, etc.) - our bright participants wont mind registering on yet another wiki and picking up from there. However, after bouncing the idea off a few participants the consensus was not to make the change in mid-stream and rather wait until after the event.
Implications
Participants should create user names on WikiEducator which match their user names on the JavaSpecialists wiki. If that user name is taken (e.g. joao ) then a new name must be created and used instead, and the relevant links corrected. For this reason, on WikiEducator I have unlinked all user names if the user page does not exist on WikiEducator.
