Skip to main content

What sort of compatibility are we talking about?

14 replies [Last post]
robilad
Offline
Joined: 2004-05-05

A) Compliance with API/VM/Language specs?

B) Passing the TCK ?

C) Same side-effects for all, even unspecified inputs?

D) Interoperability?

E) Equal serialization?

F) Allowing code that uses unspecified sun.* packages to remain running?

G) All of the above?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
robilad
Offline
Joined: 2004-05-05

> > > The bottom line is that the lack of
> compatibility
> > > between different java implementations and the
> > advent
> > > of divergent flavors of ("open-sourced") java
> will
> > > only make the language non-portable & hence less
> > > pervasive.
> >
> > I disagree. Many free software runtimes run on
> > platforms where no non-free-software runtimes have
> > been before (or will ever be, I fear). I believe
> that
> > they only add to the portability & pervasiveness
> of
> > the language and the APIs.
> >
> That is not what the quoted message states.
> You're talking about free versus non-free, the
> message you say you disagree with talks about
> technical issues.

That's not how I interpret my writing ;)

Let me try to put it in hopefully clearer terms: On many platforms, there are no ports of Sun's implementation available. For many (hobbyist, embedded, research, non-mainstream) platforms, chances are there will never be a port available, since the labour cost of porting and getting the port certified to be allowed to distribute it, is higher than the expected financial returns. So on these platforms, free software runtimes are, and presumably will be, the only game in town.

So, technically speaking, the availability of free software runtimes for 'Java-inspired' languages and APIs on platforms where there are no non-free implementations increases the range (i.e. the 'portability & pervasiveness' the original poster was talking about) of platforms on which Java bytecode can be executed.

> The multitude of JVMs and language specs that would
> flood the market were the JLS to be opened up as ESR
> advocates would cause the Java platform to diverge as
> much as or more than the many different C dialects
> across platforms.

http://dmoz.org/Computers/Programming/Languages/Java/Extensions/

Despite the long existence of extensions to the Java programming language, the Java(TM) platform seems still to exist without the negative effects that you are afraid of. Quite in contrary, some of the research done on those extensions has lead to improvements in the next J2SE 5.0 platform release, like generics.

> > I doubt that the topic of compatibility has much
> to
> > do with the topic of license choice for a
> particular
> > implementation.
> >
> No, it is quite linked. See above as to the why.

I'm sorry, I fail to see the link. Would you care to elaborate?

I'd also like to point out, that this thread is *not* about licensing conditions of Sun's implementation or specifications. It is about finding out what 'compatibility' is supposed to mean, precisely.

sheina
Offline
Joined: 2004-11-01

I'm talking about performance comptibility between jaa versions. I already tried to ask this, but I did receive any answer.

I have a program makeing socket connections. The same program compiled and run under java_1.4x returns the socket in much less than 1 second, but compiled and run under java_1.5, the socket is returned after 45 seconds !!! I have no idea what to do to have the same timeing performance ( or better !!!! ).

Somebody !!! please !!!!! thank you

linuxhippy
Offline
Joined: 2004-01-07

I think its really mad.

Of course, if you only have on implementation, then compatibility is no problem at all. (In fact there are no other so called "java" implementations out there, 95% of their classpath is licensed from sun).

asjf
Offline
Joined: 2003-06-10

> It is about finding out what 'compatibility' is supposed to mean, precisely

you seem to be after a method for achieving a perfect form of compatiblilty from the platonic realm? :)

so "Write Once, Run Anywhere" is not 100% the whole story, but compared with the state of the art before this, it is a big step forward

i think the best we can hope for is an executable definition of what compatibility consists of (TCK), which is in turn backed by formal documents

so for the fundamental questions of what is the language, what is the bytecode we have documents

for the definitions of library behaviour we have the javadocs, and for the myriad corner-cases we have the TCK

when conflicts are found, a decision has to be made and the TCK + docs updated, and implementations have to conform to this

as long as the decisions are made centrally, and there is a clear point when the debate ends, is seems ok

i think this is the point after all - the idea of "compatibility" is really about who provides the authoritative voice about what is java - Sun and the JCP seem to the best place for this - so open-source implementations if you want but not the design and definition

so perhaps your question is where does the design end and the implementation begin?

robilad
Offline
Joined: 2004-05-05

> > It is about finding out what 'compatibility' is
> supposed to mean, precisely
>
> you seem to be after a method for achieving a perfect
> form of compatiblilty from the platonic realm? :)

Well ... I'm interested in different opinions, and seeing what people associate with what's a rather vague term, in my opinion. The choices I presented in the question came from some discussions I had with other Java developers on JavaLobby, where different persons had different notions of compatibility.

Given that I actively participate in development of free software runtimes that try to be compatible with Sun's implementation, I've had a lot of fun implementing some ocasionally poorly written specs myself ;) And of course, I am interested in seeing what sort of compatibility expectations developers outside the free software camp have.

> so "Write Once, Run Anywhere" is not 100% the whole
> story, but compared with the state of the art before
> this, it is a big step forward

I'm more interested in the verifiable, reachable aspects of compatibility than in marketing slogans :) But I agree that a runtime that tries to be compatible with the Java platform needs to support the native binary format and instruction set. I'm not aware of any freely available test suite for the virtual machine specification, though.

> i think the best we can hope for is an executable
> definition of what compatibility consists of (TCK),
> which is in turn backed by formal documents

I'm not quite convinced, given that a specification can have virtually untestable assertions. See the J2SE 1.4 API docs for many java.lang.Runtime methods for examples.

> so for the fundamental questions of what is the
> language, what is the bytecode we have documents

If that only was true ;)

Sun has repeatedly modified the class file format's major version between JDK 1.1 and 1.4.2 releases, so I assume that they modified the format in some backward incompatible ways. But there is no publicly available specification of those changes, as far as I can tell.

Sun has also done quite a bit of work on fixing ambiguities in the language specification, judging by the release notes describing the changes to javac between each release. Again, there is no publicly available specification of those changes, as far as I can tell, just a bit of ocasional handwaving in the release notes, like in the case of class file format changes.

> for the definitions of library behaviour we have the
> javadocs, and for the myriad corner-cases we have the
> TCK

That's the theory, at least. I've yet to meet someone who's ever seen the mythical J2SE TCK, though, to confirm that it really exists, that it actually tests anything, i.e. if it really tests corner cases at all. It may as well be vaporware, for all I can tell from Sun's website.

> when conflicts are found, a decision has to be made
> and the TCK + docs updated, and implementations have
> to conform to this

I agree with the need for a conflict resolution mechanism between the TCK and the specification. I don't agree with a requirement that implementations conform to the latest TCK & specifications. A vendor may be no longer interested in providing a runtime, for example, or in bearing the cost that comes with updating the implementation to be compliant with an updated specification and TCK.

> i think this is the point after all - the idea of
> "compatibility" is really about who provides the
> authoritative voice about what is java - Sun and the
> JCP seem to the best place for this - so open-source
> implementations if you want but not the design and
> definition

My experiences with the silent class file format updates (which is a rather foundational part of the platform) suggest that whoever maintains the specifications is not doing a perfect job keeping them up to date with the pace of the implementation, unfortunately.

I don't think publishing the specification documents under an open source license would fix that. While it would be a lot better than the current specification license, I don't think the license of specifications has anything to do with compatibility.

> so perhaps your question is where does the design end
> and the implementation begin?

I guess a better question is rather if 'compatibility' is a static property of an implementation, or if it is a dynamic process, like 'security'?

bharathch
Offline
Joined: 2004-02-16

The bottom line is that the lack of compatibility between different java implementations and the advent of divergent flavors of ("open-sourced") java will only make the language non-portable & hence less pervasive. Such opensourcing will do more harm than good to the language.
This is as open & yet [b]compatible + platform independent[/b] as the language can get.Let's not strangulate it.Stallman & ESR can shout themselves hoarse on this. (I just can't believe they're not seeing the big picture and missing the underpinning theme.Their rhetoric in favour of open-sourcing of java will indirectly,ultimately benefit .NET & hence M$)

robilad
Offline
Joined: 2004-05-05

> The bottom line is that the lack of compatibility
> between different java implementations and the advent
> of divergent flavors of ("open-sourced") java will
> only make the language non-portable & hence less
> pervasive.

I disagree. Many free software runtimes run on platforms where no non-free-software runtimes have been before (or will ever be, I fear). I believe that they only add to the portability & pervasiveness of the language and the APIs.

> Such opensourcing will do more harm than
> good to the language.

I doubt that the topic of compatibility has much to do with the topic of license choice for a particular implementation.

> This is as open & yet [b]compatible + platform
> independent[/b] as the language can get.

Perl.

> Let's not
> strangulate it.Stallman & ESR can shout themselves
> hoarse on this.

I don't recall Stallman shouting. As far as I recall, he kindly pointed out [1] that many implementations of Java are not free software, so that people who write free software for Java on non-free runtimes could put their software in the awkward situation that others would need non-free software to make full use of it. He pointed out that there are free software platforms that are viable alternatives to Java, so that developers could make a choice whether they really need to base their free software on a non-free platform or not.

None of that has anything to do with compatibility, as far as I can tell, though. So, would you be so kind and post your definition of compatibility?

[1] http://www.newsforge.com/programming/04/04/07/2021242.shtml

jwenting
Offline
Joined: 2003-12-02

> > The bottom line is that the lack of compatibility
> > between different java implementations and the
> advent
> > of divergent flavors of ("open-sourced") java will
> > only make the language non-portable & hence less
> > pervasive.
>
> I disagree. Many free software runtimes run on
> platforms where no non-free-software runtimes have
> been before (or will ever be, I fear). I believe that
> they only add to the portability & pervasiveness of
> the language and the APIs.
>
That is not what the quoted message states.
You're talking about free versus non-free, the message you say you disagree with talks about technical issues.
The multitude of JVMs and language specs that would flood the market were the JLS to be opened up as ESR advocates would cause the Java platform to diverge as much as or more than the many different C dialects across platforms.
This would be the end of WORA which is the main strength of Java.
Of course that's the main reason ESR and cronies want Java open sourced, because they want Java to fail.

> > Such opensourcing will do more harm than
> > good to the language.
>
> I doubt that the topic of compatibility has much to
> do with the topic of license choice for a particular
> implementation.
>
No, it is quite linked. See above as to the why.

philwebster
Offline
Joined: 2003-06-11

> The multitude of JVMs and language specs that would
> flood the market were the JLS to be opened up as ESR
> advocates would cause the Java platform to diverge as
> much as or more than the many different C dialects
> across platforms.
> This would be the end of WORA which is the main
> strength of Java.
> Of course that's the main reason ESR and cronies want
> Java open sourced, because they want Java to fail.

Do you have a reference to any statements by ESR which clearly indicate a desire to open the Sun Java API/VM implementations *as well as* the language specification?

I've heard you repeating this many times all over the web, and I'm just wondering where you got it from. Obviously your opinion must be based on a factual observation of something Raymond has actually said, or else you'd be lying...

mthornton
Offline
Joined: 2003-06-10

The second trick in this question is part (a). What does compliance actually mean when the meaning of the specification is open to doubt. The spec has improved with time (just look at the documentation for things like File.renameTo over a series of revisions), but no doubt there remain many loop holes and even erroneous statements. E.g. File.setLastModified says "All platforms support file-modification times to the nearest second, but some provide more precision.", but Windows FAT file systems only record modification times to the nearest EVEN second. This may be a minor point, but I know of quite a few applications (usually Unix derived) which have problems on Windows for exactly this reason.

So what many people do, when faced with ambiguities or errors in the spec, is that they look at the source code and thus base their code on the behaviour of a particular implementation.

In principle I would like to see compliance meaning A, B and D. But currently not all of the specs are of adequate quality to give a reasonable assurance of compatible behaviour.

robilad
Offline
Joined: 2004-05-05

> So what many people do, when faced with ambiguities
> or errors in the spec, is that they look at the
> source code and thus base their code on the behaviour
> of a particular implementation.

The follow-up question would be if that's such a good thing to do. How well can 'coding to a particular implementation' work if the resulting code is expected to 'run anywhere'? What sort of compatibility can code written for a particular implementation demand or expect?

cheers,
dalibor topic

mthornton
Offline
Joined: 2003-06-10

Incompatible serialisation already occurs when the same code is compiled by different compilers and serialVersionUID is not specified explicitly. This happens because different compilers may legitimately generate different synthetic methods and these are included in the computation of serialVersionUID.

robilad
Offline
Joined: 2004-05-05

> Incompatible serialisation already occurs when the
> same code is compiled by different compilers and
> serialVersionUID is not specified explicitly. This
> happens because different compilers may legitimately
> generate different synthetic methods and these are
> included in the computation of serialVersionUID.

Yep, good answer, you recognized the trap :)

How about the other options?

cheers,
dalibor topic

asjf
Offline
Joined: 2003-06-10

imho..

B as long as it implies A,D and possibly E

certainly not F

for C some pragmatism in the form of it was unspecified but reasonable to assume would be the best option