Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29586 > unrolled thread

what are java specsification? what are reference implementation?

Back to article view | Back to comp.lang.java.programmer

Contents

  what are java specsification? what are reference implementation? www <xsli2@yahoo.com> - 2014-08-08 07:46 -0700
    Re: what are java specsification? what are reference implementation? Josip Almasi <joe@vrspace.org> - 2014-08-08 17:28 +0200
      Re: what are java specsification? what are reference implementation? Jeff Higgins <jeff@invalid.invalid> - 2014-08-09 04:24 -0400
        Re: what are java specsification? what are reference implementation? Josip Almasi <joe@vrspace.org> - 2014-08-10 13:26 +0200
    Re: what are java specsification? what are reference implementation? Jeff Higgins <jeff@invalid.invalid> - 2014-08-08 15:55 -0400
    Re: what are java specsification? what are reference implementation? Roedy Green <see_website@mindprod.com.invalid> - 2014-08-08 18:37 -0700
      Re: what are java specsification? what are reference implementation? Robert Klemme <shortcutter@googlemail.com> - 2014-08-09 12:29 +0200
        Re: what are java specsification? what are reference implementation? Roedy Green <see_website@mindprod.com.invalid> - 2014-08-12 03:04 -0700
          Re: what are java specsification? what are reference implementation? Robert Klemme <shortcutter@googlemail.com> - 2014-08-18 08:08 -0700
            Re: what are java specification? what are reference implementation? Roedy Green <see_website@mindprod.com.invalid> - 2014-08-18 23:28 -0700
            Re: what are java specsification? what are reference implementation? Arne Vajhøj <arne@vajhoej.dk> - 2014-08-19 11:17 -0400
              Re: what are java specsification? what are reference implementation? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-19 17:42 +0100
              Re: what are java specsification? what are reference implementation? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2014-08-19 23:08 -0500
    Re: what are java specsification? what are reference implementation? "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-08-09 11:17 +0100

#29586 — what are java specsification? what are reference implementation?

I found confused about these concepts. For me, a regular Java developer, I just use this tool, that tool, etc.

For example, they say JAXB(Java Architecture Xml Binding) is a specification. There are several implementations for it, blah, blah. When I am learning how to use it, I just use it in Eclipse, without knowing what I am using.

Correct me if I am wrong: is specification such thing? Many Java software developers feel they need some feature (not existing yet). Then they write into a document, specifying what they really want. Then some Oracle Java Committee reviews the request and hopefully approves it, then release this document, as JSR x.y.z

Then many talented Java developers in the world who have nothing better to do then write the code(without being paid) to do such tasks as specified in JSR x.y.z. So they could be making the same or similar wheels.

One version of the program written by one company(maybe Oracle itself) which implements JSR x.y.z is chosen to be reference implementation.

One example is Java EE. Java EE is a specification. In another words, it is a stack of documents. There are many implementation to it. IBM has WebSphere. Oracle has GlassFish. They all perform what Java EE spec wants. GlassFish is the reference implementation. To me, reference implementations sounds like the default one.

Is my understanding above correct? Thank you.

[toc] | [next] | [standalone]

#29587

On 08/08/2014 04:46 PM, www wrote:
> I found confused about these concepts. For me, a regular Java developer, I just use this tool, that tool, etc.
>
> For example, they say JAXB(Java Architecture Xml Binding) is a specification. There are several implementations
> for it, blah, blah. When I am learning how to use it, I just use it in Eclipse, without knowing what I am using.

That's OK; there's so many of it all, who cares about specifics?;)
The important thing with JAXB is - compatibility problem with 
specification:)

> Correct me if I am wrong: is specification such thing?

No.
Eventually you get into specifics and tie to one vendor.
If not during development, then after deployment, for it simplifies 
maintenance.

> Many Java software developers feel they need some feature (not existing yet). Then they write into a
> document, specifying what they really want. Then some Oracle Java Committee reviews the request and
> hopefully approves it, then release this document, as JSR x.y.z

Yes.
But you can also apply to be member of that 'some' committee.
And in fact many of these developers and their companies are.
They only require you to send them pact with the devil sealed with your 
blood;)
It's called Java Community Process and is slow, slooow... but it works.

> Then many talented Java developers in the world who have nothing better to do then write the code(without being paid)

I hope that people who write free implementations are getting something 
out of it somehow.
Certanly a lot of free software is backed by commercial companies of all 
sizes.

> to do such tasks as specified in JSR x.y.z. So they could be making the same or similar wheels.
>
> One version of the program written by one company(maybe Oracle itself) which implements JSR x.y.z is chosen to be reference implementation.
>
> One example is Java EE. Java EE is a specification. In another words, it is a stack of documents. There are many implementation to it.
> IBM has WebSphere. Oracle has GlassFish. They all perform what Java EE spec wants. GlassFish is the reference implementation.
> To me, reference implementations sounds like the default one.
>
> Is my understanding above correct? Thank you.

Correct mostly I think. With a few exceptions, like java mail reference 
implementation, jboss beating oracle etc.
There's just a handful examples of beating them in their own game.

Regards...

[toc] | [prev] | [next] | [standalone]

#29593

On 08/08/2014 11:28 AM, Josip Almasi wrote:
> On 08/08/2014 04:46 PM, www wrote:
>> I found confused about these concepts. For me, a regular Java
>> developer, I just use this tool, that tool, etc.
>>
>> For example, they say JAXB(Java Architecture Xml Binding) is a
>> specification. There are several implementations
>> for it, blah, blah. When I am learning how to use it, I just use it in
>> Eclipse, without knowing what I am using.
>
> That's OK; there's so many of it all, who cares about specifics?;)
> The important thing with JAXB is - compatibility problem with
> specification:)
>
>> Correct me if I am wrong: is specification such thing?
>
> No.
> Eventually you get into specifics and tie to one vendor.
> If not during development, then after deployment, for it simplifies
> maintenance.
>
>> Many Java software developers feel they need some feature (not
>> existing yet). Then they write into a
>> document, specifying what they really want. Then some Oracle Java
>> Committee reviews the request and
>> hopefully approves it, then release this document, as JSR x.y.z
>
> Yes.
> But you can also apply to be member of that 'some' committee.
> And in fact many of these developers and their companies are.
> They only require you to send them pact with the devil sealed with your
> blood;)
> It's called Java Community Process and is slow, slooow... but it works.

JSR 358: A major revision of the Java Community Process
<https://jcp.org/en/jsr/detail?id=358>
This JSR will make a variety of changes and adjustments to the Java
Community Process, revising the Process Document, the EC Standing
Rules, and the JSPA.

 From the current Process document,
Section 1.1 EXPERT GROUP TRANSPARENCY:
"... Expert Groups must operate in a transparent manner, enabling the
public to observe their deliberations and to provide feedback"

>> Then many talented Java developers in the world who have nothing
>> better to do then write the code(without being paid)
>
> I hope that people who write free implementations are getting something
> out of it somehow.
> Certanly a lot of free software is backed by commercial companies of all
> sizes.
>
>> to do such tasks as specified in JSR x.y.z. So they could be making
>> the same or similar wheels.
>>
>> One version of the program written by one company(maybe Oracle itself)
>> which implements JSR x.y.z is chosen to be reference implementation.
>>
>> One example is Java EE. Java EE is a specification. In another words,
>> it is a stack of documents. There are many implementation to it.
>> IBM has WebSphere. Oracle has GlassFish. They all perform what Java EE
>> spec wants. GlassFish is the reference implementation.
>> To me, reference implementations sounds like the default one.
>>
>> Is my understanding above correct? Thank you.
>
> Correct mostly I think. With a few exceptions, like java mail reference
> implementation, jboss beating oracle etc.
> There's just a handful examples of beating them in their own game.
>
> Regards...

[toc] | [prev] | [next] | [standalone]

#29618

On 08/09/2014 10:24 AM, Jeff Higgins wrote:
>
>  From the current Process document,
> Section 1.1 EXPERT GROUP TRANSPARENCY:
> "... Expert Groups must operate in a transparent manner, enabling the
> public to observe their deliberations and to provide feedback"

ALLRIGHT!

Yeah I really hated it all secret until given perimission to publish.

Regards...

[toc] | [prev] | [next] | [standalone]

#29590

On 08/08/2014 10:46 AM, www wrote:
> I found confused about these concepts.
> Is my understanding above correct? Thank you.

RTFS
To reduce confusion and increase understanding
please read the fine specification.

GIYF
To assist your search for the fine specification:
please use the terms jsr+355.

[toc] | [prev] | [next] | [standalone]

#29591

On Fri, 8 Aug 2014 07:46:58 -0700 (PDT), www <xsli2@yahoo.com> wrote,
quoted or indirectly quoted someone who said :

>Then many talented Java developers in the world who have nothing better to =
>do then write the code(without being paid) to do such tasks as specified in=
> JSR x.y.z. So they could be making the same or similar wheels.

There is nothing to stop someone writing a commercial implementation
of that spec.  They have to produce something faster, with more
features if they want to compete with free implementations.

The idea was people without budget could use a free implementation,
and if the project were a roaring success, they could relatively
easily migrate to a more gold plated implementation.

SQL is the granddaddy of this sort of thinking. The problem is the
spec is so loose, it is a major task to migrate to a different
engine..  They don't even use identical syntax for identical
functions, and there is no guarantee even basic functionality has to
be supported.

It is time a new tighter spec.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [next] | [standalone]

#29595

On 09.08.2014 03:37, Roedy Green wrote:

> The idea was people without budget could use a free implementation,
> and if the project were a roaring success, they could relatively
> easily migrate to a more gold plated implementation.
>
> SQL is the granddaddy of this sort of thinking. The problem is the
> spec is so loose, it is a major task to migrate to a different
> engine..  They don't even use identical syntax for identical
> functions, and there is no guarantee even basic functionality has to
> be supported.
>
> It is time a new tighter spec.

I don't think the spec is to blame.  The issue is that implementations 
were around before the different versions of the spec and vendors chose 
compatibility to their older versions over compatibility to a recent 
standard of SQL.  In some cases there is no way to provide both - 
standard and custom syntax at the same time (e.g. Oracle's data type 
DATE which is really a timestamp while in the standard it is really a 
date only).

So, as always, having a good specification is one thing - the adherence 
of implementations to the spec is another.  With commercial vendors 
there is usually a tendency to provide features that break or at least 
extend a standard to allow for vendor lock in.  As you can see, in case 
of Oracle databases that works pretty well.  Of course, users of those 
products would prefer more independence but they seem to have enough 
advantages of using a proprietary product to continue to do so.

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#29641

On Sat, 09 Aug 2014 12:29:29 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote, quoted or indirectly quoted
someone who said :

>I don't think the spec is to blame. 

The spec came too late, and then the spec had no teeth, so it was
almost useless.

To be useful, it must let you take code and move it around from vendor
to vendor , and as long as you stick to the spec, it still works.
Vendors should be allowed to extend, but not do variants on the core.

Vendors WANT to lock their customers in. Customers want to be able to
move.  The problem is vendors are the ones writing the spec.

Java as a spec is much tighter than usual, and has done a better job
than anyone on WORA.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The art of strongly-typed language design is largely arranging 
that errors are automatically detected as soon as possible
in the compose, compile, run cycle.

[toc] | [prev] | [next] | [standalone]

#29713

On Tuesday, August 12, 2014 12:04:49 PM UTC+2, Roedy Green wrote:
> On Sat, 09 Aug 2014 12:29:29 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote, quoted or indirectly quoted
> someone who said :
> 
> >I don't think the spec is to blame. 
> 
> The spec came too late, and then the spec had no teeth, so it was
> almost useless.

Still, it's the vendors that must implement it.  You cannot blame the spec.  It's never the spec's fault - unless, maybe, if the spec is inconsistent or in other ways weak thus forcing implementers of the spec to find "creative solutions".

> To be useful, it must let you take code and move it around from vendor
> to vendor , and as long as you stick to the spec, it still works.
> Vendors should be allowed to extend, but not do variants on the core.

You cannot enforce this.  That is totally unrealistic.  Worst case they will drop claim to implement SQL standard - but for users it will still look reasonably close so they use it as if.

> Vendors WANT to lock their customers in. Customers want to be able to
> move.  The problem is vendors are the ones writing the spec.

I think you are idealistic here (and I have probably grown too pragmatic).

> Java as a spec is much tighter than usual, and has done a better job
> than anyone on WORA.

No, it's not the spec that did the good job but vendors implementing it.  Luckily for Java there were only few vendors and one of them happened to be the driving force behind the spec as well.

Cheers

robert

[toc] | [prev] | [next] | [standalone]

#29717 — Re: what are java specification? what are reference implementation?

On Mon, 18 Aug 2014 08:08:08 -0700 (PDT), Robert Klemme
<shortcutter@googlemail.com> wrote, quoted or indirectly quoted
someone who said :

>No, it's not the spec that did the good job but vendors
 implementing it.  Luckily for Java there were only few vendors
 and one of them happened to be the driving force behind the
 spec as well.

Thinking way back, didn't the US military invent an extensive test
suite you had to pass if you wanted to claim you had an Ada compiler?
There were some "almost Ada" implementations, but they could not call
themselves Ada.

In think, inventing WORA specs in general should get easier as
efficient low level code becomes less important.

What C, for example, aims for is ability to port the same code base to
different platforms using sufficient macro preprocessing.
Understanding multiplatform code is perhaps an order of magnitude more
daunting than understanding single platform code.

Java aims for running the same class file on any platform and getting
the same output, even if the screens and fonts look different.

To make WORA even stronger, a language would have to include a set of
perhaps 20 fonts guaranteed to be present with guaranteed font
metrics.

SQL is pretty old.  IIRC I first encountered it back in the 1970s.  It
was not considered efficient enough for general database use. It was
for ad hoc queries on warehouse data only.  Coding ad hoc queries was
pretty much out of the question in the old days since it took so much
code and skill. Perhaps a government body could issue a WORA standard 
with teeth, and say that if you want government business, you had
better pull yourself into gradual conformance within X years gradually
tightening the noose like a deer tag. You would start with easy things
like standard names for data types.


To do ad hoc queries, in the 1970s I invented a suite of utilities
that worked on flat files that clerks could use. To my astonishment
they would concoct chains utilities 100 steps long. I never conceived
them being used in chains of more than about 4 steps long. At the
time, being able to prepare charts, graphs for court for a new
question with a hour's notice seemed impossible. Today it is nothing.



-- 
Roedy Green Canadian Mind Products http://mindprod.com
Errors using inadequate data are much less than those using no data at all. 
~ Charles Babbage (born: 1791-12-26 died: 1871-10-18 at age: 79)

[toc] | [prev] | [next] | [standalone]

#29725

On 8/18/2014 11:08 AM, Robert Klemme wrote:
> On Tuesday, August 12, 2014 12:04:49 PM UTC+2, Roedy Green wrote:
>> Java as a spec is much tighter than usual, and has done a better job
>> than anyone on WORA.
>
> No, it's not the spec that did the good job but vendors implementing it.  Luckily for Java there were only few vendors and one of them happened to be the driving force behind the spec as well.

I think you need to give more credit to the spec.

The Java spec has a few strong points:
* it is a relative simple language and VM
* the description is relative detailed
* there is very little undefined and implementation specific behavior

That really helps WORA.

On top of that SUN had a couple of policies in place that additionally
helped:
* large technical compatibility kit to verify compliance
* proven record of suing for millions if some software claimed to be
   Java but could not pass the test

Arne

[toc] | [prev] | [next] | [standalone]

#29727

Arne Vajhøj wrote:

> The Java spec has a few strong points:
> * it is a relative simple language and VM
> * the description is relative detailed
> * there is very little undefined and implementation specific behavior
>
> That really helps WORA.

Also relatively short (1 or 2 book's-length).  Sufficiently readable that 
people actually /could/ (and did) read it.

Which not only makes the implementers job easier, but also makes it more likely 
that implementers would face specific pressures from their users actually to 
follow the spec.

(Later revisions of the Java spec have, to a large extent, lost those virtues, 
but the good start ensured that everyone could start "on the same foot" at 
least.)

    -- chris 

[toc] | [prev] | [next] | [standalone]

#29756

On 8/19/2014 10:17 AM, Arne Vajhøj wrote:
> On 8/18/2014 11:08 AM, Robert Klemme wrote:
>> On Tuesday, August 12, 2014 12:04:49 PM UTC+2, Roedy Green wrote:
>>> Java as a spec is much tighter than usual, and has done a better job
>>> than anyone on WORA.
>>
>> No, it's not the spec that did the good job but vendors implementing
>> it.  Luckily for Java there were only few vendors and one of them
>> happened to be the driving force behind the spec as well.
>
> I think you need to give more credit to the spec.
>
> The Java spec has a few strong points:
> * it is a relative simple language and VM
> * the description is relative detailed
> * there is very little undefined and implementation specific behavior

I don't think these help as much as you think. The core C syntax, for 
example, is about equally simple in both syntax and semantics as Java's 
syntax and semantics, even with the plethora of undefined and 
implementation-defined behavior. It even turns out that said behaviors 
are also rather portable: char is in practice signed everywhere and 8 
bits, integers are 2's complement, and even the undefined overflow is 
going to be optimized the same across all major implementations.

The problems with portability in C--or in most languages, for that 
matter--really come down to cases where there is serious disagreement 
among implementations: the size of pointers in C, for example, or path 
names in any language. You can make it portable if you're careful, but 
you can also easily write nonportable code.

Another problematic aspect of portability is that there are different 
expectations about what should be portable. If I ran a tight Java loop 
inside some code measuring the time it took to execute, the fact that 
I'm not going to get consistent values for that time isn't usually 
considered a portability issue. If I ran a tight loop in the assembly 
code of, say, an old Atari console, and that loop took different times 
in hardware versus an emulator, I very much would consider that a major 
bug in the emulator's implementation.

Rather, I think the single biggest factor is that the Java specification 
has only one major implementation, and the specification and that 
implementation can co-evolve. In the face of any question over the 
standard, you can really just point at the Sun (now Oracle) JVM and say 
"do what that does."

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#29594

www wrote:

> Correct me if I am wrong: is specification such thing? Many Java software
> developers feel they need some feature (not existing yet). Then they
> write into a document, specifying what they really want. Then some Oracle
> Java Committee reviews the request and hopefully approves it, then
> release this document, as JSR x.y.z

I think the more common approach is that the specification is produced in 
tandem with the reference implementation -- with some overlap between the 
groups producing the two "products".

Thus the reference implementation is usually the first to be released (quite 
possibly before the actual standard[*]), and is the implementation that proves 
that the specification can actually be implemented and is (at least somewhat) 
useful.

There then may be one or more other implementations produced by people who 
think that they can improve upon the reference implementation in any of many 
different ways (e.g. integration into an existing product, 
faster/smaller/cheaper implementation, branded by <some big name>, ...).

Of course, another way that standards get born is when several similar but 
competing products agree on a common standard -- but in such cases there 
typically won't be any /reference/ implementation (at least I can't think of 
any examples).

    -- chris

[*] not necessarily before any "draft standards" but a "draft standard" isn't 
really a standard at all, just a discussion document. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web