Randy McMurchy wrote:
> Bruce Dubbs wrote these words on 03/08/08 10:44 CST:
> 
>> I would like to add an alternative view.  Although having a binary
>> package in the book is not preferable, I think this can be an exception.
> 
> Your view is highly appreciated. After thinking about it, I'm
> not sure we need to comment out the source installation at all.
> It is from late September last year which means it is not even
> six months old yet.
> 
> I don't see the harm in placing a note on the JDK page explaining
> the situation with the Sun devels and why the source build uses
> jar files much older than the binary files.
> 
> That way the user can *decide for herself* if she wants the binary
> or source version. Additionally, it keeps the instructions for the
> source build around for reference or whatever.
> 

This sounds good, so long as the vulnerabilities are mentioned.

> 
>>  The text could describe the circumstances why we are making that
>> exception.  It could also say that the source installation procedures
>> are expected to be in the next version of the book when OpenJDK is released.
> 
> But that could be a *long* time. DJ mentioned that not until the
> version 7 will it be considered a stable release. No telling when
> that may come about.
> 
Clarification on that.  There will be stable builds of OpenJDK6. 
Whether or not the OpenJDK6 code base is used for the official binary 
releases in the future is still undecided.  Which also prompts me to 
explain (the rest of this message is probably OT, but some might like 
the read of current status and history).

The OpenJDK6 Merc repository was created from OpenJDK7 and modified to 
meet JCK6a (Sun's internal compatibility testing framework) so that it 
is a compatible release with the official JDK6.  All of the questionable 
licensing ('encumbered code' - code that Sun licensed from others and 
couldn't acquire so they could open them up) was removed first in 
OpenJDK7, but there are still some minor hurdles to overcome WRT 
compatibility.

The JPEG classes, previously deprecated since at least original JDK6 
release, are now removed, though they still exist in the official 
builds.  It's my opinion that is not an issue since you were warned by 
the compiler to fix your code for the passed year or more.

MIDI isn't present, though stubs are there, which will soon be 
implemented by the Gervil project, which was recently added in OpenJDK7.

OpenJDK6 is almost fully functional now, but there is still one 
remaining, unrelated regression for JCK6a.  I don't recall off the top 
of my head what that was.  Anyway, it'll be soon, just not soon enough 
for BLFS-6.3.

Also, Dan just mentioned IcedTea as an alternative, but it's following 
the same codebase and suffers the same deficiencies as OpenJDK6 right 
now, except that they have stubs for the missing JPEG classes. :-)  They 
also have a nice build system I'm told, though I haven't tried it.

Anyway, I'll leave u3 source in the book for now with a warning and 
explanation.  There's no telling, sun might even surprise us.

-- DJ Lucas

-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to