Java Spotlight Episode 129: Anthony Lai on JSR 236 Java EE Concurrency Utilities @jcp
By Roger Brinkley on Apr 23, 2013
Interview with Anthony Lai on JSR 236 Concurrency Utilities for Java EE.
Right-click or Control-click to download this MP3 file. You can also subscribe to the Java Spotlight Podcast Feed to get the latest podcast automatically. If you use iTunes you can open iTunes and subscribe with this link: Java Spotlight Podcast in iTunes.
- Oracle Java ME Embedded 3.3 for ARM Cortex M3 reference binary integrated with RTX OS for the Keil board released. Terrence Barr’s blog, webcast “Getting started with Java ME Embedded on KEIL” (part 1, part 2), binary, Angela Caicedo’s blog post ”Getting started with Java ME Embedded on KEIL”.
- Critical Patch Updates Java 7u21, Release Notes on 7u21, and the Critical Patch Update notes.
- Proposed new schedule for JDK 8 and supporting Java 8: Secure the Train blog by Mark Reinhold.
- 7u communication Schedule and release renumbering update.
- Apr 23-24, JavaOne Moscow, Russia
- May 8-9, JavaOne Hyderabad, India
- May 10, GIDS, Bangalore, India
- May 14, Java Day Tokyo
- May 18-19, Geecon, Poland
- May 22-24, GR8Conf, Denmark
- May 24-25, JEEConf, Kiev
- Jun 3-5, JAX Conf, Santa Clara, USA
Feature InterviewAnthony Lai is a principal member of the Oracle technical staff and a developer in the J2EE Connector Architecture area of Oracle Application Server Containers of J2EE. Anthony is also a member of the expert committee for the J2EE Connector Architecture 1.5 specification (JSR 112) and the specification lead for JSR 236 Concurrency Utilities for Java EE.
Mail BagTetsuo wrote:
I think requiring signing applets is the right path. It's a little harder to developers? It's their (well, our) job to understand and handle this kind of thing, not the users'.
I have one question, though:
Currently, when we sign an applet, it can run outside the sandbox (that means, it could read and/or write to any file the current user has access to, run native commands with Runtime.exec(), etc.). I think it asks for permission, but I think it's almost a given that now, when you accept to run a signed applet, you're authorising it to run outside the sandbox (otherwise, there would be little incentive to sign it in the first place) and do whatever it wants to your computer.
If all applets now will require signing and user approval to run, how can the user differentiate a sandboxed applet from a run-as-admin (windows users almost always are admin) applet?
Signing in the past was only done for apps that were going to request elevated permissions. Today all apps need to be signed, but signing doesn't equated to elevated permissions. The user gets different informational prompts for sandboxed vs. privileged apps, and the app developer is is control of whether the app runs inside the sandbox (for now).
- New JEPs
- AirHacks workshops