Welcome

Greetings one and all. You're probably here because Gilad kindly pointed the way. His contributions to Sun span two millenia and have been more immense than most people know; the Java Language and VM Specifications set the bar for modern platform documentation. It is an honour to follow in his footsteps and I wish him the best of luck with his new and dynamic endeavours.

I plan to blog about interpretation of the JLS and JVMS; design issues on JSRs that I'm involved with; and proposals for language features both old and new. I also hope to bring the JLS and JVMS into the blogging age by publishing clarifications and corrections as tagged entries.

So with Java SE 6 emerging and the lifecycle for SE 7 starting - and with the debate about Java's place in the world reaching fever pitch - it will surely be the most interesting of times.

Comments:

Hello Alex, great to have you! Could you put something about yourself onto About page for the uninitiated? Dmitri

Posted by Dmitri Trembovetski on November 08, 2006 at 02:40 AM PST #

Welcome aboard !

Posted by Danny Coward on November 08, 2006 at 06:13 AM PST #

Hi and welcome. I've a perhaps no so stupid question for you. Could you explain why array creation of parametrized type is unsafe. see my blog : http://weblogs.java.net/blog/forax/archive/2006/11/why_array_of_pa.html RĂ©mi

Posted by guest on November 08, 2006 at 06:29 PM PST #

Hi Alex, I have a request: could you please take a look at bug 4689050 and tell us your ideas? The "category" field says it's a specification bug, but the evaluation says it's a compiler bug. Is the compiler ever going to conform to the spec, one way or the other?

Posted by Bas de Bakker on November 15, 2006 at 04:56 PM PST #

Hi!
I've been thinking about this for a couple of days and since you're now responsible for the JVMS, let me pitch this to you:
How about a new bytecode specification?

There is a proposal to add a new bytecode to the existing spec (http://jcp.org/en/jsr/detail?id=292), that would be solved.
It would allow to add reified generics support at the bytecode level (http://gafter.blogspot.com/2006/11/reified-generics-for-java.html). There was a proposal to add two new bytecodes when generics for java was first discussed, I don't have the url right now though.
It would allow to add unsigned data types at the bytecode level, as well as tail-recursion support.
It would allow to remove the bytecodes that have become deprecated in the new split verifier support (http://jcp.org/en/jsr/detail?id=202).
It could also allow removal of the superfluous _x instructions (for example iload_2). These were introduced to reduce the memory size. However, most class files are compressed anyway as a jar/new packed meta-package format and it might actually be worthwhile to replace those compressed instructions by non-compressed ones and leave the compression to the compressor - i.e. this could reduce the size.
It would allow stricter typing at the bytecode level (e.g. for boolean).
It would allow to remove the (arbitrary, and IMHO ultimately dangerous) 32/64 bit distinction for local variables and stack, which in turn would simplify the stack manipulation operations. That distinction was made to enable simpler implementation of an interpreter on 32 bit architectures. To reenable this, one could add a 'precompiled' mode where stack-manipulation/local variables addresses are resolved ahead of time; this could be done with a small additional reserved instruction block.
I envision dividing the bytecode into instruction blocks, one for ALU instructions, one for conversion instructions, one for control-flow instructions, one for legacy-support (32/64 bit precompilation).
Furthermore, if done right, this new bytecode would be conversion-compatible with the old one - that is, the old one could be easily converted to the new, even behind the scenes, for legacy support. The new one could be converted to the old with a few exceptions: invokedynamic and the reified generics instructions. It would thus be conversion-compatible in both directions with all current java compilers and tools.
This change would make java much more interesting as a target for languages other than java. It would also pave the way for reified generics and unsigned data types.
Cheers, Ulf

Posted by Ulf Ochsenfahrt on February 01, 2007 at 07:11 AM PST #

Post a Comment:
Comments are closed for this entry.
About

Alex Buckley is the Specification Lead for the Java language and JVM at Oracle.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds