Hello,
I would like to know whether the "synchronized class" construct is
valid in JDK 1.5 and whether it has any meaning at all in the context
of multithreaded programming or whether the compiler will ignore it
altogether. I have read some posts stating that "synchronized class"
is not a legal way to begin a Java class definitions. Any comments
on this would be sincerely appreciated.
Thanks,
JG
Chris Smith - 31 Jan 2006 17:18 GMT
> I would like to know whether the "synchronized class" construct is
> valid in JDK 1.5 and whether it has any meaning at all in the context
> of multithreaded programming or whether the compiler will ignore it
> altogether. I have read some posts stating that "synchronized class"
> is not a legal way to begin a Java class definitions. Any comments
> on this would be sincerely appreciated.
Your question is answered in section 8.1.1 of the Java Language
Specification, third edition. The valid modifiers for a class are any
annotation, public, protected, private, abstract, static, final, or
strictfp. It is illegal to place the keyword "synchronized" in front of
a class.

Signature
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Thomas Hawtin - 31 Jan 2006 17:50 GMT
> I would like to know whether the "synchronized class" construct is
> valid in JDK 1.5 and whether it has any meaning at all in the context
> of multithreaded programming or whether the compiler will ignore it
> altogether. I have read some posts stating that "synchronized class"
> is not a legal way to begin a Java class definitions. Any comments
> on this would be sincerely appreciated.
JDK 1.0.2 (not sure about 1.1, certainly not 1.2) allowed "synchronized
class". That was a bug. IIRC, it set the equivalent but unassigned bit
in class file. It had, and has still, absolutely no effect on runtime
behaviour.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/
Mike Schilling - 31 Jan 2006 22:13 GMT
>> I would like to know whether the "synchronized class" construct is
>> valid in JDK 1.5 and whether it has any meaning at all in the context
[quoted text clipped - 7 lines]
> class file. It had, and has still, absolutely no effect on runtime
> behaviour.
It has a huge effect on runtime behavior now: if you can't compile a class,
it won't run.
Adam Maass - 01 Feb 2006 00:43 GMT
>>> I would like to know whether the "synchronized class" construct is
>>> valid in JDK 1.5 and whether it has any meaning at all in the context
[quoted text clipped - 10 lines]
> It has a huge effect on runtime behavior now: if you can't compile a
> class, it won't run.
If the .class file has the "synchronized" bit set for the class as a
whole...
The point was that early compilers were buggy in allowing ... synchronized
class .... they set a bit in the .class file. The value of that bit was
irrelevant to the behavior the class, and still is.
Modern compilers disallow "synchronized class". But that is a compile-time
behavior, not a runtime behavior.
Chris Uppal - 01 Feb 2006 08:39 GMT
> The point was that early compilers were buggy in allowing ... synchronized
> class .... they set a bit in the .class file. The value of that bit was
> irrelevant to the behavior the class, and still is.
Incidentally, the ACC_SYNCHRONISED bit, 0x0020, has been reinterpreted for
classes and now signifies the almost indescribably hacky ACC_SUPER flag.
ACC_SUPER is required (by the JVM spec) to be set for all classes compiled by
"new" compilers:
The setting of the ACC_SUPER flag indicates which of two alternative
semantics for its invokespecial instruction the Java virtual machine is
to express; the ACC_SUPER flag exists for backward compatibility for
code compiled by Sun's older compilers for the Java programming language.
All new implementations of the Java virtual machine should implement
the semantics for invokespecial documented in this specification. All new
compilers to the instruction set of the Java virtual machine should set the
ACC_SUPER flag. Sun's older compilers generated ClassFile flags with
ACC_SUPER unset. Sun's older Java virtual machine implementations
ignore the flag if it is set.
With characteristic imprecision the spec doesn't state which editions of the
Java platform are required to interpret the flag.
-- chris