Tuesday Mar 27, 2012

the OpenJDK group at Oracle is growing

The OpenJDK software development team at Oracle is hiring. To get an idea of what we’re looking for, go to the Oracle recruitment portal and enter the Keywords “Java Platform Group” and the Location Keywords “Santa Clara”.  (We are a global engineering group based in Santa Clara.)  It’s pretty obvious what we are working on; just dive into a public OpenJDK repository or OpenJDK mailing list.

Here is a typical job description from the current crop of requisitions:

The Java Platform group is looking for an experienced, passionate and highly-motivated Software Engineer to join our world class development effort. Our team is responsible for delivering the Java Virtual Machine that is used by millions of developers. We are looking for a development engineer with a strong technical background and thorough understanding of the Java Virtual Machine, Java execution runtime, classloading, garbage collection, JIT compiler, serviceability and a desire to drive innovations.

As a member of the software engineering division, you will take an active role in the definition and evolution of standard practices and procedures. You will be responsible for defining and developing software for tasks associated with the developing, designing and debugging of software applications or operating systems.

Work is non-routine and very complex, involving the application of advanced technical/business skills in area of specialization. Leading contributor individually and as a team member, providing direction and mentoring to others. BS or MS degree or equivalent experience relevant to functional area. 7 years of software engineering or related experience.

Friday Dec 02, 2011

suppressing warnings this month

The OpenJDK community just had a nice sprint cleaning up warnings in JDK code. I did my bit; it was fun.

Two questions came up during reviews, one about the equivalence of wildcards and named type parameters, and one about the best way to handle creation of an array of generic element types.

Here's the quick summary of how to write arrays of generics:

@SuppressWarnings("unchecked")  // array creation must have wildcard
List<String>[] lss = (List<String>[]) new List<?>[1];
In the common case where desired type parameter is wild, there is no need to suppress warnings:
List<?>[] lqs = new List<?>[1];
Class<?>[] cs = new Class<?>[1];

Note that every use of @SuppressWarnings should have a comment. Also, every @SuppressWarnings should be placed on the smallest possible program element, usually a local variable declaration.

Here's an example of removing a deprecation warning. A typical deprecation warning is:

Foo.java:876: warning: [deprecation] String(byte[],int) in String has been deprecated
String x = new String(new byte[0], 0);
Here a the corresponding fix:
@SuppressWarnings("deprecation")  // String(byte[],int) in String has been deprecated
// and this is actually useful because the fremdish preskittler was exsufflated
String x = new String(new byte[0], 0);
The clarifying comment is a useful way to record any extra information (if known) why the deprecated method is being used.

Saturday Mar 28, 2009

JSR 292 support in javac

In order to work with dynamic types, method handles, and invokedynamic I have made some provisional changes to javac as part of the Da Vinci Machine Project. (There is a full description for Project COIN; it's almost ready for publication, and I'll blog about that when I push it.) It is most desirable, of course, to program invokedynamic call sites as Java expressions, not just ASM code, and that's what those langtools patches are for.[Read More]

Wednesday Aug 01, 2007

Scope ambiguities between outer and super

A decade ago, I briefly contributed to this topic in an aside in the original whitepaper from Sun:
Sometimes the combination of inheritance and lexical scoping can be confusing. For example, if the class E inherited a field named array from Enumeration, the field would hide the parameter of the same name in the enclosing scope. To prevent ambiguity in such cases, Java 1.1 allows inherited names to hide ones defined in enclosing block or class scopes, but prohibits them from being used without explicit qualification.
This rule has been dubbed the "Mother May I" rule...[Read More]

Tuesday Jun 05, 2007

June Language Dynamics

Charles Nutter has started an interesting Google Group which is worth the attention of language wonks:

I recently spent a pleasant hour thinking about Common Lisp on the JVM; see this thread:
  http://groups.google.com/group/jvm-languages (Kicking off: Jatha)

Meanwhile, the JSR 292 Expert Group will be working this summer on a simplified POC (proof of concept) that can serve as the basis for coordinated experiments in JVM and language implementation.

I expect that when we have something that passes the red-face test, we will be soliciting comments and experiments, based on open source bases. This is not the Final Answer, but simply the Initial Answer.

Thursday May 10, 2007

Longjumps Considered Inexpensive

...You can pre-allocate an exception and use it as many times as you want.... With current server VM optimizations of this technique, the cost of a non-local return is less than three times the cost of a plain (local) return; with the client VM the ratio is ten. See the code example and benchmark for details: NonLocalExit.java (javadoc).

...Languages on the JVM (including Java, if that’s the direction it goes) can implement non-local returns reasonably directly, and the JITs will turn them into local jumps in important common cases.

[Read More]

Wednesday May 09, 2007

JSR 292 Deep Dive Notes

We had a productive pick-up meeting at JavaOne. Here are my minutes.[Read More]

Sunday May 06, 2007

Whither JSR 292?

As of March I'm the chair of JSR 292.... The most likely work this calendar year includes a specification and prototype for a first version of invokedynamic, and a demonstration of the benefits for a few major dynamic languages....

[Read More]

Saturday Jan 06, 2007

Autonomous Methods for the JVM

...Because the JVM is a highly successful investment in efficient and robust support for byte-coded methods, it is worth while looking at teasing apart JVM methods from JVM classes. If this can be done well, the strengths of the JVM can be applied to programming tasks (scripting, functional programming) beyond the current scope of Java.

So, here is a design sketch for autonomous methods (AM) in the JVM. It is not complete, but should be suggestive of new ways to support languages beyond Java....

[Read More]

Wednesday Jan 03, 2007

Duck Typing in the JVM

There's a thought-provoking post about invokedynamic and duck typing here: http://headius.blogspot.com/2007/01/invokedynamic-actually-useful.html

Charles asks, "Would all methods accept Object and return Object? Is that useful?"

[Read More]

Thursday Aug 31, 2006

Better Closures

As I mentioned earlier, a closure per se has a special nature which it does not share with other kinds of functions. A closure is produced from snippet of code, written in the midst of a larger block of code, in such a way that the meaning of names within the snippet are consistent with the enclosing block.

Let‘s continue to examine the case for (a) better closures and (b) slightly better type parameters but not (c) function types, with the most enjoyable part, (a).[Read More]

Friday Aug 25, 2006

Closures without Function Types

Java needs (a) better closures and (b) slightly better type parameters but not (c) function types. Let's examine the last first...[Read More]

John R. Rose

Java maven, HotSpot developer, Mac user, Scheme refugee.

Once Sun and present Oracle engineer.


« April 2014