Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   synchronized class (http://www.velocityreviews.com/forums/t149824-synchronized-class.html)

John Goche 01-31-2006 04:23 PM

synchronized class
 
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 01-31-2006 05:18 PM

Re: synchronized class
 
John Goche <johngoche@gmail.com> wrote:
> 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.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Thomas Hawtin 01-31-2006 06:02 PM

Re: synchronized class
 
John Goche wrote:
>
> 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
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

Mike Schilling 01-31-2006 10:13 PM

Re: synchronized class
 

"Thomas Hawtin" <usenet@tackline.plus.com> wrote in message
news:43dfa14e$0$1491$ed2619ec@ptn-nntp-reader01.plus.net...
> John Goche wrote:
>>
>> 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.


It has a huge effect on runtime behavior now: if you can't compile a class,
it won't run.



Adam Maass 02-01-2006 12:43 AM

Re: synchronized class
 

"Mike Schilling" <mscottschilling@hotmail.com> wrote:
> "Thomas Hawtin" <usenet@tackline.plus.com> wrote:
>> John Goche wrote:
>>>
>>> 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.

>
> 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 02-01-2006 08:39 AM

Re: synchronized class
 
Adam Maass wrote:

> 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




All times are GMT. The time now is 01:34 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.