From slushpupie at gmail.com  Tue Apr  8 12:23:13 2008
From: slushpupie at gmail.com (Jay Kline)
Date: Tue, 8 Apr 2008 14:23:13 -0500
Subject: CryptoPermssion object missing?
Message-ID: <ace41e70804081223n12b9d120w35e12a69429283af@mail.gmail.com>

Im trying to figure out how to check what the permissions of the JCE
allow at runtime and have run into a bit of a stumbling block.  The
policy file uses javax.crypto.CryptoPermission as the permission name,
and from what I can tell in the JCE for 1.4 that existed as an object,
and it appears to be in the openjdk for 6 and 7.  However, the Sun JDK
has no such object (either 5 or 6).

What is the correct way to check for these permissions then? Its a
little confusing since I cant seem to determine if that object should
really exist.

Thanks,

Jay


From David.Herron at Sun.COM  Tue Apr  8 13:30:25 2008
From: David.Herron at Sun.COM (David Herron)
Date: Tue, 08 Apr 2008 13:30:25 -0700
Subject: CryptoPermssion object missing?
In-Reply-To: <ace41e70804081223n12b9d120w35e12a69429283af@mail.gmail.com>
References: <ace41e70804081223n12b9d120w35e12a69429283af@mail.gmail.com>
Message-ID: <47FBD5E1.1000503@sun.com>

Jay Kline wrote:
> Im trying to figure out how to check what the permissions of the JCE
> allow at runtime and have run into a bit of a stumbling block.  The
> policy file uses javax.crypto.CryptoPermission as the permission name,
> and from what I can tell in the JCE for 1.4 that existed as an object,
> and it appears to be in the openjdk for 6 and 7.  However, the Sun JDK
> has no such object (either 5 or 6).
>
> What is the correct way to check for these permissions then? Its a
> little confusing since I cant seem to determine if that object should
> really exist.
>
> Thanks,
>
> Jay
>   
I want to add to what Jay wrote, as we were talking about this on IRC a 
few minutes ago.

Using Google I found that class is mentioned in one page on java.sun.com:
http://java.sun.com/j2se/1.4.2/docs/guide/security/jce/JCERefGuide.html

That class is not listed in the javadoc for java6
http://java.sun.com/javase/6/docs/api/index.html

It would appear to me this class (and maybe some others?) should not be 
in openjdk6 because we intend openjdk6 to pass JCK6.  But I don't know 
enough of the security end of the platform and clearly I could be mistaken.

- David Herron



From Sharon.Liu at Sun.COM  Tue Apr  8 17:07:38 2008
From: Sharon.Liu at Sun.COM (Sharon Liu)
Date: Tue, 08 Apr 2008 17:07:38 -0700
Subject: CryptoPermssion object missing?
Message-ID: <47FC08CA.7060301@sun.com>

Jay,

> Im trying to figure out how to check what the permissions of the JCE
> allow at runtime
What the JCE allows at runtime is defined in the JCE jurisdiction policy 
file.

> The policy file uses javax.crypto.CryptoPermission as the permission name,
> and from what I can tell in the JCE for 1.4 that existed as an object,
> and it appears to be in the openjdk for 6 and 7.  However, the Sun JDK
> has no such object (either 5 or 6).

The javax.crypto.CryptoPermission class isn't a public class since it
is only used by the JCE framework internally at runtime. This class
exists in Sun's JDK 5 and 6 as well.

Hope this helps,
Sharon


Subject:
CryptoPermssion object missing?
From:
Jay Kline <slushpupie at gmail.com>
Date:
Tue, 08 Apr 2008 14:23:13 -0500

To:
jdk6-dev at openjdk.java.net


Im trying to figure out how to check what the permissions of the JCE
allow at runtime and have run into a bit of a stumbling block.  The
policy file uses javax.crypto.CryptoPermission as the permission name,
and from what I can tell in the JCE for 1.4 that existed as an object,
and it appears to be in the openjdk for 6 and 7.  However, the Sun JDK
has no such object (either 5 or 6).

What is the correct way to check for these permissions then? Its a
little confusing since I cant seem to determine if that object should
really exist.

Thanks,

Jay




From java2004kto at yahoo.fr  Wed Apr  9 00:22:06 2008
From: java2004kto at yahoo.fr (JKT)
Date: Wed, 09 Apr 2008 09:22:06 +0200
Subject: JSR105 - Other SignatureMethod implementation ?
In-Reply-To: <ace41e70804081223n12b9d120w35e12a69429283af@mail.gmail.com>
References: <ace41e70804081223n12b9d120w35e12a69429283af@mail.gmail.com>
Message-ID: <47FC6E9E.1090308@yahoo.fr>

Hi  to all,

I tried to generated a xmldsig signature by using the JSR105 API. It 
works well except the fact that I cannot use other signature methods 
than DSA_SHA1, RSA_SHA1 and HMAC_SHA1.

Indeed, I would like to sign an object by using SHA256withRSA algorithm 
(the digest method SHA256 is already implemented in this version). After 
having downloaded the source of  SUN's jsr105 implementation, i 
discovered that i could not use another algorithm without changing the 
source code.

Does any somebody know if the next version of Sun's jsr105 
implementation will include other signature algorithms ?

Thanks for your answer.

Best regards,

JKT.







From David.Herron at Sun.COM  Wed Apr  9 09:33:44 2008
From: David.Herron at Sun.COM (David Herron)
Date: Wed, 09 Apr 2008 09:33:44 -0700
Subject: JSR105 - Other SignatureMethod implementation ?
In-Reply-To: <47FC6E9E.1090308@yahoo.fr>
References: <ace41e70804081223n12b9d120w35e12a69429283af@mail.gmail.com>
	<47FC6E9E.1090308@yahoo.fr>
Message-ID: <47FCEFE8.20009@sun.com>

JKT wrote:
> Hi  to all,
>
> I tried to generated a xmldsig signature by using the JSR105 API. It 
> works well except the fact that I cannot use other signature methods 
> than DSA_SHA1, RSA_SHA1 and HMAC_SHA1.
>
> Indeed, I would like to sign an object by using SHA256withRSA 
> algorithm (the digest method SHA256 is already implemented in this 
> version). After having downloaded the source of  SUN's jsr105 
> implementation, i discovered that i could not use another algorithm 
> without changing the source code.
>
> Does any somebody know if the next version of Sun's jsr105 
> implementation will include other signature algorithms ?
>
> Thanks for your answer.
>
> Best regards,
>
> JKT.
>


I suggest you'd have better luck asking this question in the 
security-dev list..

http://mail.openjdk.java.net/mailman/listinfo/security-dev



From Joe.Darcy at Sun.COM  Fri Apr 11 16:46:53 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 11 Apr 2008 16:46:53 -0700
Subject: OpenJDK 6 b09 source posted
Message-ID: <47FFF86D.6030901@sun.com>

Hello.

The OpenJDK 6 b09 source is now available at

http://download.java.net/openjdk/jdk6/

Notable fixes in this build include linux printing issues:

6633656: Cross platform print dialog doesn't check for orientation being 
unsupported.
6678161: Printing to remote non-Postscript printer does not work in Linux.

a correction to the JAX-WS 2.0 -> 2.1 upgrade:

6672868:Package javax.xml.ws.wsaddressing not included in 
make/docs/CORE_PKGS.gmk

and some time zone updates:

6650748 (tz) Java runtime doesn't detect VET time zone correctly on Windows
6679340 (tz) Support tzdata2008b

This will very likely be the last source drop until after JavaOne.

-Joe


From David.Herron at Sun.COM  Fri Apr 18 12:16:25 2008
From: David.Herron at Sun.COM (David Herron)
Date: Fri, 18 Apr 2008 12:16:25 -0700
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box,
	GTK L&F, Ubuntu 7.10
Message-ID: <4808F389.9050403@sun.com>

I saw the following question from Tom Fitzsimmons and that it did not CC 
the jdk6-dev alias.

Tom, I take it you're requesting this fix for jdk6-dev?

- David Herron


Subject:
Re: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box, GTK 
L&F, Ubuntu 7.10
From:
Thomas Fitzsimmons <fitzsim at redhat.com>
Date:
Fri, 18 Apr 2008 09:39:15 -0400

To:
kirill.kirichenko at sun.com
CC:
jdk7-changes at openjdk.java.net, swing-dev at openjdk.java.net


kirill.kirichenko at sun.com wrote:
> Changeset: eecc88fb2430
> Author:    stayer
> Date:      2008-04-11 16:25 +0400
> URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/eecc88fb2430
>
> 6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10
> Reviewed-by: peterz
>
> ! src/solaris/native/sun/awt/gtk2_interface.c
>

Will this be committed to the jdk6 tree as well?

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080418/38fb3707/attachment.html 

From David.Herron at Sun.COM  Fri Apr 18 12:57:53 2008
From: David.Herron at Sun.COM (David Herron)
Date: Fri, 18 Apr 2008 12:57:53 -0700
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box,
	GTK L&F, Ubuntu 7.10
In-Reply-To: <4808F954.1080109@redhat.com>
References: <4808F389.9050403@sun.com> <4808F954.1080109@redhat.com>
Message-ID: <4808FD41.6020703@sun.com>

It depends on what Kirill meant by "jdk6".

OpenJDK6 != JDK6 .. in that the OpenJDK6 tree is not related to the tree 
which produces the 6 update releases.  Therefore fixes in JDK6 do not 
automatically roll into OpenJDK6.  The situation is different in 
OpenJDK7/JDK7 where they are nearly the same source trees.  There are 
hysterical historical reasons to this unfortunate situation.

The bug as it stands is not targeted to OpenJDK 6.  Unless I'm missing 
something it's also not targeted to JDK6.

- David Herron



Thomas Fitzsimmons wrote:
> Yes, Kirill replied privately saying that the fix will be committed to 
> the jdk6 tree.  I guess that means we can expect it in the next 
> OpenJDK 6 tarball?
>
> Tom
>
> David Herron wrote:
>> I saw the following question from Tom Fitzsimmons and that it did not 
>> CC the jdk6-dev alias.
>>
>> Tom, I take it you're requesting this fix for jdk6-dev?
>>
>> - David Herron
>>
>>
>> Subject:
>> Re: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box, GTK 
>> L&F, Ubuntu 7.10
>> From:
>> Thomas Fitzsimmons <fitzsim at redhat.com>
>> Date:
>> Fri, 18 Apr 2008 09:39:15 -0400
>>
>> To:
>> kirill.kirichenko at sun.com
>> CC:
>> jdk7-changes at openjdk.java.net, swing-dev at openjdk.java.net
>>
>>
>> kirill.kirichenko at sun.com wrote:
>>> Changeset: eecc88fb2430
>>> Author:    stayer
>>> Date:      2008-04-11 16:25 +0400
>>> URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/eecc88fb2430
>>>
>>> 6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10
>>> Reviewed-by: peterz
>>>
>>> ! src/solaris/native/sun/awt/gtk2_interface.c
>>>
>>
>> Will this be committed to the jdk6 tree as well?
>>
>> Tom
>



From fitzsim at redhat.com  Fri Apr 18 12:41:08 2008
From: fitzsim at redhat.com (Thomas Fitzsimmons)
Date: Fri, 18 Apr 2008 15:41:08 -0400
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box,
	GTK L&F, Ubuntu 7.10
In-Reply-To: <4808F389.9050403@sun.com>
References: <4808F389.9050403@sun.com>
Message-ID: <4808F954.1080109@redhat.com>

Yes, Kirill replied privately saying that the fix will be committed to the jdk6 
tree.  I guess that means we can expect it in the next OpenJDK 6 tarball?

Tom

David Herron wrote:
> I saw the following question from Tom Fitzsimmons and that it did not CC 
> the jdk6-dev alias.
> 
> Tom, I take it you're requesting this fix for jdk6-dev?
> 
> - David Herron
> 
> 
> Subject:
> Re: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box, GTK 
> L&F, Ubuntu 7.10
> From:
> Thomas Fitzsimmons <fitzsim at redhat.com>
> Date:
> Fri, 18 Apr 2008 09:39:15 -0400
> 
> To:
> kirill.kirichenko at sun.com
> CC:
> jdk7-changes at openjdk.java.net, swing-dev at openjdk.java.net
> 
> 
> kirill.kirichenko at sun.com wrote:
>> Changeset: eecc88fb2430
>> Author:    stayer
>> Date:      2008-04-11 16:25 +0400
>> URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/eecc88fb2430
>>
>> 6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10
>> Reviewed-by: peterz
>>
>> ! src/solaris/native/sun/awt/gtk2_interface.c
>>
> 
> Will this be committed to the jdk6 tree as well?
> 
> Tom



From Joe.Darcy at Sun.COM  Fri Apr 18 13:23:34 2008
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 18 Apr 2008 13:23:34 -0700
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box,
	GTK L&F, Ubuntu 7.10
In-Reply-To: <4808FD41.6020703@sun.com>
References: <4808F389.9050403@sun.com> <4808F954.1080109@redhat.com>
	<4808FD41.6020703@sun.com>
Message-ID: <48090346.4020402@sun.com>

David Herron wrote:
> It depends on what Kirill meant by "jdk6".
>
> OpenJDK6 != JDK6 .. in that the OpenJDK6 tree is not related to the 
> tree which produces the 6 update releases.  Therefore fixes in JDK6 do 
> not automatically roll into OpenJDK6.  The situation is different in 
> OpenJDK7/JDK7 where they are nearly the same source trees.  There are 
> hysterical historical reasons to this unfortunate situation.

> The bug as it stands is not targeted to OpenJDK 6.  Unless I'm missing 
> something it's also not targeted to JDK6.

Looking at the bug, there is a lot of interest in having this fixed in 
evidence on bugs.sun.com and the fix seems limited to localized changes 
in one file.  I've created a sub for this issue for OpenJDK 6; Kirill, 
please put the fix back there too.

-Joe

> - David Herron
>
>
>
> Thomas Fitzsimmons wrote:
>> Yes, Kirill replied privately saying that the fix will be committed 
>> to the jdk6 tree.  I guess that means we can expect it in the next 
>> OpenJDK 6 tarball?
>>
>> Tom
>>
>> David Herron wrote:
>>> I saw the following question from Tom Fitzsimmons and that it did 
>>> not CC the jdk6-dev alias.
>>>
>>> Tom, I take it you're requesting this fix for jdk6-dev?
>>>
>>> - David Herron
>>>
>>>
>>> Subject:
>>> Re: <Swing Dev> hg: jdk7/swing/jdk: 6624717: Corrupted combo box, 
>>> GTK L&F, Ubuntu 7.10
>>> From:
>>> Thomas Fitzsimmons <fitzsim at redhat.com>
>>> Date:
>>> Fri, 18 Apr 2008 09:39:15 -0400
>>>
>>> To:
>>> kirill.kirichenko at sun.com
>>> CC:
>>> jdk7-changes at openjdk.java.net, swing-dev at openjdk.java.net
>>>
>>>
>>> kirill.kirichenko at sun.com wrote:
>>>> Changeset: eecc88fb2430
>>>> Author:    stayer
>>>> Date:      2008-04-11 16:25 +0400
>>>> URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/eecc88fb2430
>>>>
>>>> 6624717: Corrupted combo box, GTK L&F, Ubuntu 7.10
>>>> Reviewed-by: peterz
>>>>
>>>> ! src/solaris/native/sun/awt/gtk2_interface.c
>>>>
>>>
>>> Will this be committed to the jdk6 tree as well?
>>>
>>> Tom
>>
>



From doko at ubuntu.com  Tue Apr 22 05:22:00 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Tue, 22 Apr 2008 14:22:00 +0200
Subject: another review of copyright/license stuff in openjdk-b09
Message-ID: <480DD868.2060003@ubuntu.com>

Recently Thomas Viehmann did a thorough review of the openjdk-b09 source if all
licenses are DFSG-free *and* have copyrights and licenses accurately documented,
as a prerequisite to upload a package to the Debian distribution.

Some files were skipped in the review, which are already removed from the source
for i.e. the Fedora build. See
http://cvs.fedoraproject.org/viewcvs/devel/java-1.6.0-openjdk/generate-fedora-zip.sh?rev=1.2&view=markup
for a list.

The rest of the email are Thomas comments (some comments added by myself).

  Matthias

Hi all,

as discussed with Matthias, here is a preliminary report for my check of openjdk
in NEW. The check is not yet complete, but I took a stab at evaluating all text
files not particularly hidden (e.g. in jars) that have their copyright
information near the top of the file.

Apologies for this being a bit terse, should it be too short
on anything, don't hesitate to ask.

I'll try to skip the files removed by the fedora-make-zip script, as
Matthias points out, we probably should remove these as well.
There are some additional binaries missed by Fedora(?).
This is a problem and needs to be solved, e.g.
(pathnames assume you have unpacked the main tarball in openjdk)
  openjdk/jdk/test/java/util/Locale/data/deflocale.exe
  openjdk/jdk/test/tools/launcher/lib/sparc/lib32/liblibrary.so
and more *.exe *.so.

fedora-make-zip removes
openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/first.set
 *    THIS PRODUCT CONTAINS RESTRICTED MATERIALS OF IBM
 *    5639-D57, (C) COPYRIGHT International Business Machines Corp., 1997, 1998
but not
openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/idl.prp
openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/idl_*.prp
openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable*.prp
# Licensed Materials - Property of IBM
# 5639-D57 (C) COPYRIGHT International Business Machines Corp., 1997, 1999
# RMI-IIOP v1.0

Missing copyrights in debian/copyright (or short d/c) (which includes a copy of
the third party readme), need be fixed/checked:

- openjdk/jdk/src/share/classes/java/lang/instrument/package.html
   Copyright 2003 Wily Technology, Inc. License?

- %% This notice is provided with respect to PC/SC Lite for Suse Linux v. 1.1.1,
  which may be included with this software:

  Copyright (c) 1999-2004 David Corcoran
  All rights reserved.
  needs to be Ludovic Rousseau for e.g.
  openjdk/jdk/src/solaris/native/sun/security/smartcardio/MUSCLE/winscard.h

- the Eastman Kodak see below?
- RSA Security Inc. see below?

Some inaccuracies in debian/copyright, should be fixed:
- Sax is said to be public domain in d/c, but Sun claims copyright
  for some of these and licenses under GPL, e.g.
  openjdk/jaxp/src/share/classes/org/xml/sax/HandlerBase.java
  >> in THIRD_PARTY_README as well

- Apache Software Foundation owns copyrights up to 2005

- at least parts of Xerces (and Xalan, but that could be the
  destinction between Xalan J2 and Xalan in d/c) uses
  Apache License 2.0, not just Apache Software license 1.1
  e.g.
openjdk/jaxp/src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/VoidType.java
- jaxp/src/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java
-
openjdk/jaxp/src/share/classes/com/sun/xml/internal/stream/XMLEntityReader.java
  has Portions Copyright Sun Microsystems, Inc. in addition
  to ASF,
-
jaxp/src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeValueException.java
  has a note a la "based on software (c) ... IBM ...", don't know if
  that should be mentioned, some more might have that nearby.
-
openjdk/jdk/src/share/classes/com/sun/org/apache/xml/internal/security/Init.java
  and more like it: some xml security is Apache License 2.0,
  debian/copyright says ASL1.1
- %% This notice is provided with respect to IAIK PKCS Wrapper, which may be
included with this software:
  Copyright (c) 2002 Graz University of Technology. All rights reserved.
  should have sun with portions copyright
  e.g.
openjdk/jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_RANDOM_DATA.jav
- openjdk/jdk/src/share/classes/sun/security/krb5/PrincipalName.java
  * Portions Copyright 2000-2006 Sun Microsystems, Inc.  All Rights  Reserved.
  ...
  *  (C) Copyright IBM Corp. 1999 All Rights Reserved.
  *  Copyright 1997 The Open Group Research Institute.  All rights reserved./*
  and some nearby

- This notice is provided with respect to Kerberos, which may be included with
this software:
  * Copyright (C) 1998 by the FundsXpress, INC.
  could be more specific and / or list other copyright holders to the
  krb5 stuff, fundsxpress seems to own only one (?) file.

Question for the following files: can these be edited/modfied using free tools?

- openjdk/jaxws/src/share/classes/com/sun/xml/internal/bind/v2/doc-files/
  the .gif and .png files built from .vsd and .sxd files are corrupt,
  cannot be opened. The .sxd file is probably an OOo Impress file, but
  cannot be opened with OOo 2.4. The .vsd file is a Viso file? If yes,
  can the packages.png generated by free software?

- openjdk/jdk/test/sun/net/idn/nfscis.spp


- openjdk/jdk/test/javax/xml/crypto/dsig/data/xml-stylesheet
  has w3c copyright. license to be checked.
  openjdk/jdk/test/javax/xml/crypto/dsig/data/xml-stylesheet.b64
  needs checking after decoding

Some minor things regarding copyright:
- openjdk/jdk/make/sun/javazic/tzdata
  has sun copyright notices that I'm not too sure about (AFAICT some of
  it is just verbatim public domain tzdata).
- openjdk/jdk/make/tools/dtdbuilder/dtds/html32.dtd:
  sun copyright?
- openjdk/jdk/src/share/classes/java/awt/image/renderable/RenderContext.java
  Portions Copyright 1998-2000 Sun Microsystems, Inc.  All Rights Reserved.
  DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  ...
  COPYRIGHT (c) Eastman Kodak Company, 1997
  As  an unpublished  work pursuant to Title 17 of the United
  States Code.  All rights reserved.
  also some more nearby, presumably Sun has licensed that to allow this?

- some files around
  openjdk/jdk/src/share/classes/java/awt/dnd/DragSourceContext.java:
  have import statements in the license note ?!

- openjdk/jdk/src/share/native/sun/awt/libpng/pngtrans.c
  looks strange because of the non-exception GPL notice, probably Sun
  cosmetic mistake.

openjdk/jdk/src/share/native/sun/security/pkcs11/wrapper/pkcs11.h
 /* FILENAME include file for PKCS #11. */
/* $Revision: 1.4 $ */

/* License to copy and use this software is granted provided that it is
 * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
 * (Cryptoki)" in all material mentioning or referencing this software.

 * License is also granted to make and use derivative works provided that
 * such works are identified as "derived from the RSA Security Inc. PKCS #11
 * Cryptographic Token Interface (Cryptoki)" in all material mentioning or
 * referencing the derived work.

 * RSA Security Inc. makes no representations concerning either the
 * merchantability of this software or the suitability of this software for
 * any particular purpose. It is provided "as is" without express or implied
 * warranty of any kind.
 */
some simmilar nearby, probably needs entry in the third party readme

openjdk/jdk/src/share/classes/sun/text/resources/CollationData_sr.java
 * (C) Copyright Taligent, Inc. 1996, 1997 - All Rights Reserved
 * (C) Copyright IBM Corp. 1996 - 1998 - All Rights Reserved

openjdk/jdk/src/share/classes/sun/text/resources/BreakIteratorRules_th.java
 * IBM Confidential
 * OCO Source Materials
 * IBM Java(tm)2 SDK, Standard Edition, v 1.2
 * (C) Copyright IBM Corp. 1999

openjdk/jdk/src/share/classes/sun/util/resources/CurrencyNames_*.properties
  has sun+unicode copyright (possibly already covered)

- Probable non issue:
  openjdk/jdk/make/sun/rmi/rmic/FILES.gmk
  ...
  # Generated by IBM JTC-SV tools.genmake
  --> probably just templating(?)

Kind regards

T.



From Joe.Darcy at Sun.COM  Tue Apr 22 13:30:22 2008
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Tue, 22 Apr 2008 13:30:22 -0700
Subject: another review of copyright/license stuff in openjdk-b09
In-Reply-To: <480DD868.2060003@ubuntu.com>
References: <480DD868.2060003@ubuntu.com>
Message-ID: <480E4ADE.9030702@sun.com>

Matthias,

Thanks for sending along the copyright analysis.  On the point of Sun 
copyrights on public domain information, IANAL, I'm just an engineer, 
but my understanding is that it is permissible, if unfriendly, to put 
your own copyright notice on public domain files.

I'll start us looking into these issues, but we are in the crush ahead 
of JavaOne.

-Joe

Matthias Klose wrote:
> Recently Thomas Viehmann did a thorough review of the openjdk-b09 source if all
> licenses are DFSG-free *and* have copyrights and licenses accurately documented,
> as a prerequisite to upload a package to the Debian distribution.
>
> Some files were skipped in the review, which are already removed from the source
> for i.e. the Fedora build. See
> http://cvs.fedoraproject.org/viewcvs/devel/java-1.6.0-openjdk/generate-fedora-zip.sh?rev=1.2&view=markup
> for a list.
>
> The rest of the email are Thomas comments (some comments added by myself).
>
>   Matthias
>
> Hi all,
>
> as discussed with Matthias, here is a preliminary report for my check of openjdk
> in NEW. The check is not yet complete, but I took a stab at evaluating all text
> files not particularly hidden (e.g. in jars) that have their copyright
> information near the top of the file.
>
> Apologies for this being a bit terse, should it be too short
> on anything, don't hesitate to ask.
>
> I'll try to skip the files removed by the fedora-make-zip script, as
> Matthias points out, we probably should remove these as well.
> There are some additional binaries missed by Fedora(?).
> This is a problem and needs to be solved, e.g.
> (pathnames assume you have unpacked the main tarball in openjdk)
>   openjdk/jdk/test/java/util/Locale/data/deflocale.exe
>   openjdk/jdk/test/tools/launcher/lib/sparc/lib32/liblibrary.so
> and more *.exe *.so.
>
> fedora-make-zip removes
> openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/first.set
>  *    THIS PRODUCT CONTAINS RESTRICTED MATERIALS OF IBM
>  *    5639-D57, (C) COPYRIGHT International Business Machines Corp., 1997, 1998
> but not
> openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/idl.prp
> openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/idl_*.prp
> openjdk/corba/src/share/classes/com/sun/tools/corba/se/idl/toJavaPortable/toJavaPortable*.prp
> # Licensed Materials - Property of IBM
> # 5639-D57 (C) COPYRIGHT International Business Machines Corp., 1997, 1999
> # RMI-IIOP v1.0
>
> Missing copyrights in debian/copyright (or short d/c) (which includes a copy of
> the third party readme), need be fixed/checked:
>
> - openjdk/jdk/src/share/classes/java/lang/instrument/package.html
>    Copyright 2003 Wily Technology, Inc. License?
>
> - %% This notice is provided with respect to PC/SC Lite for Suse Linux v. 1.1.1,
>   which may be included with this software:
>
>   Copyright (c) 1999-2004 David Corcoran
>   All rights reserved.
>   needs to be Ludovic Rousseau for e.g.
>   openjdk/jdk/src/solaris/native/sun/security/smartcardio/MUSCLE/winscard.h
>
> - the Eastman Kodak see below?
> - RSA Security Inc. see below?
>
> Some inaccuracies in debian/copyright, should be fixed:
> - Sax is said to be public domain in d/c, but Sun claims copyright
>   for some of these and licenses under GPL, e.g.
>   openjdk/jaxp/src/share/classes/org/xml/sax/HandlerBase.java
>   >> in THIRD_PARTY_README as well
>
> - Apache Software Foundation owns copyrights up to 2005
>
> - at least parts of Xerces (and Xalan, but that could be the
>   destinction between Xalan J2 and Xalan in d/c) uses
>   Apache License 2.0, not just Apache Software license 1.1
>   e.g.
> openjdk/jaxp/src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/VoidType.java
> - jaxp/src/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java
> -
> openjdk/jaxp/src/share/classes/com/sun/xml/internal/stream/XMLEntityReader.java
>   has Portions Copyright Sun Microsystems, Inc. in addition
>   to ASF,
> -
> jaxp/src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeValueException.java
>   has a note a la "based on software (c) ... IBM ...", don't know if
>   that should be mentioned, some more might have that nearby.
> -
> openjdk/jdk/src/share/classes/com/sun/org/apache/xml/internal/security/Init.java
>   and more like it: some xml security is Apache License 2.0,
>   debian/copyright says ASL1.1
> - %% This notice is provided with respect to IAIK PKCS Wrapper, which may be
> included with this software:
>   Copyright (c) 2002 Graz University of Technology. All rights reserved.
>   should have sun with portions copyright
>   e.g.
> openjdk/jdk/src/share/classes/sun/security/pkcs11/wrapper/CK_SSL3_RANDOM_DATA.jav
> - openjdk/jdk/src/share/classes/sun/security/krb5/PrincipalName.java
>   * Portions Copyright 2000-2006 Sun Microsystems, Inc.  All Rights  Reserved.
>   ...
>   *  (C) Copyright IBM Corp. 1999 All Rights Reserved.
>   *  Copyright 1997 The Open Group Research Institute.  All rights reserved./*
>   and some nearby
>
> - This notice is provided with respect to Kerberos, which may be included with
> this software:
>   * Copyright (C) 1998 by the FundsXpress, INC.
>   could be more specific and / or list other copyright holders to the
>   krb5 stuff, fundsxpress seems to own only one (?) file.
>
> Question for the following files: can these be edited/modfied using free tools?
>
> - openjdk/jaxws/src/share/classes/com/sun/xml/internal/bind/v2/doc-files/
>   the .gif and .png files built from .vsd and .sxd files are corrupt,
>   cannot be opened. The .sxd file is probably an OOo Impress file, but
>   cannot be opened with OOo 2.4. The .vsd file is a Viso file? If yes,
>   can the packages.png generated by free software?
>
> - openjdk/jdk/test/sun/net/idn/nfscis.spp
>
>
> - openjdk/jdk/test/javax/xml/crypto/dsig/data/xml-stylesheet
>   has w3c copyright. license to be checked.
>   openjdk/jdk/test/javax/xml/crypto/dsig/data/xml-stylesheet.b64
>   needs checking after decoding
>
> Some minor things regarding copyright:
> - openjdk/jdk/make/sun/javazic/tzdata
>   has sun copyright notices that I'm not too sure about (AFAICT some of
>   it is just verbatim public domain tzdata).
> - openjdk/jdk/make/tools/dtdbuilder/dtds/html32.dtd:
>   sun copyright?
> - openjdk/jdk/src/share/classes/java/awt/image/renderable/RenderContext.java
>   Portions Copyright 1998-2000 Sun Microsystems, Inc.  All Rights Reserved.
>   DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   ...
>   COPYRIGHT (c) Eastman Kodak Company, 1997
>   As  an unpublished  work pursuant to Title 17 of the United
>   States Code.  All rights reserved.
>   also some more nearby, presumably Sun has licensed that to allow this?
>
> - some files around
>   openjdk/jdk/src/share/classes/java/awt/dnd/DragSourceContext.java:
>   have import statements in the license note ?!
>
> - openjdk/jdk/src/share/native/sun/awt/libpng/pngtrans.c
>   looks strange because of the non-exception GPL notice, probably Sun
>   cosmetic mistake.
>
> openjdk/jdk/src/share/native/sun/security/pkcs11/wrapper/pkcs11.h
>  /* FILENAME include file for PKCS #11. */
> /* $Revision: 1.4 $ */
>
> /* License to copy and use this software is granted provided that it is
>  * identified as "RSA Security Inc. PKCS #11 Cryptographic Token Interface
>  * (Cryptoki)" in all material mentioning or referencing this software.
>
>  * License is also granted to make and use derivative works provided that
>  * such works are identified as "derived from the RSA Security Inc. PKCS #11
>  * Cryptographic Token Interface (Cryptoki)" in all material mentioning or
>  * referencing the derived work.
>
>  * RSA Security Inc. makes no representations concerning either the
>  * merchantability of this software or the suitability of this software for
>  * any particular purpose. It is provided "as is" without express or implied
>  * warranty of any kind.
>  */
> some simmilar nearby, probably needs entry in the third party readme
>
> openjdk/jdk/src/share/classes/sun/text/resources/CollationData_sr.java
>  * (C) Copyright Taligent, Inc. 1996, 1997 - All Rights Reserved
>  * (C) Copyright IBM Corp. 1996 - 1998 - All Rights Reserved
>
> openjdk/jdk/src/share/classes/sun/text/resources/BreakIteratorRules_th.java
>  * IBM Confidential
>  * OCO Source Materials
>  * IBM Java(tm)2 SDK, Standard Edition, v 1.2
>  * (C) Copyright IBM Corp. 1999
>
> openjdk/jdk/src/share/classes/sun/util/resources/CurrencyNames_*.properties
>   has sun+unicode copyright (possibly already covered)
>
> - Probable non issue:
>   openjdk/jdk/make/sun/rmi/rmic/FILES.gmk
>   ...
>   # Generated by IBM JTC-SV tools.genmake
>   --> probably just templating(?)
>
> Kind regards
>
> T.
>
>   



From gnu_andrew at member.fsf.org  Sun Apr 27 08:21:53 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Sun, 27 Apr 2008 16:21:53 +0100
Subject: javah output file naming weirdness
Message-ID: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>

We recently uncovered a bug in the JikesRVM
(http://jira.codehaus.org/browse/RVM-456), namely that we were relying
on the naming of the header files generated by javah being in the same
style as those generated by the proprietary Sun JDK.

As can be seen in the bug report, the breakage showed up when using
IcedTea6/OpenJDK6 to build JikesRVM.  On OpenJDK6,

javah -verbose -d
/home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/c
-classpath /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/jksvm.jar
org.jikesrvm.scheduler.greenthreads.VM_Process

produces a file named:

org_jikesrvm_scheduler_greenthreads_VM_Process.h

while apparently the proprietary version emits:

org_jikesrvm_scheduler_greenthreads_VM_0005fProcess.h

(encoding the classname's underscore character as 0005f).  We fixed
our bug by explicitly asking for javah to emit the latter named file,
but is this a regression in the OpenJDK6 version of javah?  Even the
OpenJDK I was using before (b12) still emitted the 0005f version (at
least I presume so, because the build worked...)

Any ideas?
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Alan.Bateman at Sun.COM  Sun Apr 27 17:06:23 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 28 Apr 2008 01:06:23 +0100
Subject: javah output file naming weirdness
In-Reply-To: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
Message-ID: <481514FF.9030704@sun.com>

Andrew John Hughes wrote:
> We recently uncovered a bug in the JikesRVM
> (http://jira.codehaus.org/browse/RVM-456), namely that we were relying
> on the naming of the header files generated by javah being in the same
> style as those generated by the proprietary Sun JDK.
>
> As can be seen in the bug report, the breakage showed up when using
> IcedTea6/OpenJDK6 to build JikesRVM.  On OpenJDK6,
>
> javah -verbose -d
> /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/c
> -classpath /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/jksvm.jar
> org.jikesrvm.scheduler.greenthreads.VM_Process
>
> produces a file named:
>
> org_jikesrvm_scheduler_greenthreads_VM_Process.h
>
> while apparently the proprietary version emits:
>
> org_jikesrvm_scheduler_greenthreads_VM_0005fProcess.h
>
> (encoding the classname's underscore character as 0005f).  We fixed
> our bug by explicitly asking for javah to emit the latter named file,
> but is this a regression in the OpenJDK6 version of javah?  Even the
> OpenJDK I was using before (b12) still emitted the 0005f version (at
> least I presume so, because the build worked...)
>
> Any ideas?
>   
I'm not involved in this area but I suspect this is related to the 
re-write of javah in 1.4.2. I just did a quick test with 1.4.2 to check 
and it emits the header file as VM_0005fProcess.h. Running 1.4.2's javah 
with an undocumented -Xnew option to select the "new" version causes it 
to emit VM_Process.h which is what 5.0 and newer also emits (the new 
version became the default in 5.0).  Is there any possibility you've 
been building JikesRVM with a 1.4.2 or older release? When you say that 
the OpenJDK javah was generating the 0005f version then are you sure? 
Any possibility the build worked because it was picking up a header from 
a previous build with 1.4.2 or older?

-Alan.


From rogers.email at gmail.com  Sun Apr 27 14:28:45 2008
From: rogers.email at gmail.com (Ian Rogers)
Date: Sun, 27 Apr 2008 22:28:45 +0100
Subject: javah output file naming weirdness
In-Reply-To: <481514FF.9030704@sun.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
	<481514FF.9030704@sun.com>
Message-ID: <4814F00D.8020900@gmail.com>

Alan Bateman wrote:
> Andrew John Hughes wrote:
>> We recently uncovered a bug in the JikesRVM
>> (http://jira.codehaus.org/browse/RVM-456), namely that we were relying
>> on the naming of the header files generated by javah being in the same
>> style as those generated by the proprietary Sun JDK.
>>
>> As can be seen in the bug report, the breakage showed up when using
>> IcedTea6/OpenJDK6 to build JikesRVM.  On OpenJDK6,
>>
>> javah -verbose -d
>> /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/c
>> -classpath 
>> /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/jksvm.jar 
>>
>> org.jikesrvm.scheduler.greenthreads.VM_Process
>>
>> produces a file named:
>>
>> org_jikesrvm_scheduler_greenthreads_VM_Process.h
>>
>> while apparently the proprietary version emits:
>>
>> org_jikesrvm_scheduler_greenthreads_VM_0005fProcess.h
>>
>> (encoding the classname's underscore character as 0005f).  We fixed
>> our bug by explicitly asking for javah to emit the latter named file,
>> but is this a regression in the OpenJDK6 version of javah?  Even the
>> OpenJDK I was using before (b12) still emitted the 0005f version (at
>> least I presume so, because the build worked...)
>>
>> Any ideas?
>>   
> I'm not involved in this area but I suspect this is related to the 
> re-write of javah in 1.4.2. I just did a quick test with 1.4.2 to 
> check and it emits the header file as VM_0005fProcess.h. Running 
> 1.4.2's javah with an undocumented -Xnew option to select the "new" 
> version causes it to emit VM_Process.h which is what 5.0 and newer 
> also emits (the new version became the default in 5.0).  Is there any 
> possibility you've been building JikesRVM with a 1.4.2 or older 
> release? When you say that the OpenJDK javah was generating the 0005f 
> version then are you sure? Any possibility the build worked because it 
> was picking up a header from a previous build with 1.4.2 or older?
Hi everyone and thanks for the help,

it's a requirement that the Jikes RVM is built with at least Java 5.0 
due to wide spread use of generics and annotations in the code base. I 
personally use Java 6 to build Jikes RVM (on systems with neither Java 
1.4.2 or Java 5.0 installed). The only time I've heard of a problem with 
javah is Andrew when using Open JDK 6. We could have been fluking things 
before.

Thanks again,
Ian Rogers
-- 
Third International Workshop on Implementation, Compilation, 
Optimization of Object-Oriented Languages, Programs and Systems 
(ICOOOLPS 2008)
Submissions/Notification/Conference: May 4th/May 19th/July 7th
Paphos (Cyprus) http://icoolps.loria.fr


From doko at ubuntu.com  Mon Apr 28 02:28:34 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Mon, 28 Apr 2008 11:28:34 +0200
Subject: another review of copyright/license stuff in openjdk-b09
In-Reply-To: <480DD868.2060003@ubuntu.com>
References: <480DD868.2060003@ubuntu.com>
Message-ID: <481598C2.9020308@ubuntu.com>

there some more files without source in the tarball; the majority not required
for a Linux build, however the following files are required for the build.

$ find openjdk -name '*.jar' -o -name '*.class'|grep -v test
openjdk/corba/src/share/classes/com/sun/tools/corba/se/logutil/lib/jscheme.jar
openjdk/corba/src/share/classes/com/sun/tools/corba/se/logutil/lib/jschemelogutil.jar


this is from http://jscheme.sourceforge.net/jscheme/main.html? mentioned in the
third party readme "... Altered versions may be distributed in packages under
other licenses (such as the GNU license)." I don't know if this is altered or
not, but it would make things clearer if the source is included.

openjdk/hotspot/build/linux/Queens.class
openjdk/hotspot/build/solaris/Queens.class

Couldn't find any source for these.

openjdk/hotspot/agent/kk/src/share/lib/maf-1_0.jar
openjdk/hotspot/agent/kk/src/share/lib/jlfgr-1_0.jar

no source as well, but those are not required by the build.

I didn't look at jar and class files in test directories yet.

There are some more binary files, which are not removed by the generate-fedora
script; I'm attaching my current version of the script to build the dfsg tarball.

  Matthias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: generate-dfsg-zip.sh
Type: application/x-sh
Size: 6398 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20080428/1e44cbeb/attachment.sh 

From gnu_andrew at member.fsf.org  Mon Apr 28 03:01:46 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 28 Apr 2008 11:01:46 +0100
Subject: javah output file naming weirdness
In-Reply-To: <481514FF.9030704@sun.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
	<481514FF.9030704@sun.com>
Message-ID: <17c6771e0804280301rcc82bddt560f95308d36f4f1@mail.gmail.com>

2008/4/28 Alan Bateman <Alan.Bateman at sun.com>:
> Andrew John Hughes wrote:
>
> > We recently uncovered a bug in the JikesRVM
> > (http://jira.codehaus.org/browse/RVM-456), namely that we were relying
> > on the naming of the header files generated by javah being in the same
> > style as those generated by the proprietary Sun JDK.
> >
> > As can be seen in the bug report, the breakage showed up when using
> > IcedTea6/OpenJDK6 to build JikesRVM.  On OpenJDK6,
> >
> > javah -verbose -d
> > /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/c
> > -classpath
> /home/andrew/projects/classpath/jikesrvm/target/prototype_x86_64-linux/jksvm.jar
> > org.jikesrvm.scheduler.greenthreads.VM_Process
> >
> > produces a file named:
> >
> > org_jikesrvm_scheduler_greenthreads_VM_Process.h
> >
> > while apparently the proprietary version emits:
> >
> > org_jikesrvm_scheduler_greenthreads_VM_0005fProcess.h
> >
> > (encoding the classname's underscore character as 0005f).  We fixed
> > our bug by explicitly asking for javah to emit the latter named file,
> > but is this a regression in the OpenJDK6 version of javah?  Even the
> > OpenJDK I was using before (b12) still emitted the 0005f version (at
> > least I presume so, because the build worked...)
> >
> > Any ideas?
> >
> >
>  I'm not involved in this area but I suspect this is related to the re-write
> of javah in 1.4.2. I just did a quick test with 1.4.2 to check and it emits
> the header file as VM_0005fProcess.h. Running 1.4.2's javah with an
> undocumented -Xnew option to select the "new" version causes it to emit
> VM_Process.h which is what 5.0 and newer also emits (the new version became
> the default in 5.0).  Is there any possibility you've been building JikesRVM
> with a 1.4.2 or older release? When you say that the OpenJDK javah was
> generating the 0005f version then are you sure? Any possibility the build
> worked because it was picking up a header from a previous build with 1.4.2
> or older?
>
>  -Alan.
>

Alan,


Thanks for your input.

The problem was that my javah from OpenJDK6 was _not_ emitting the
0005f that JikesRVM was relying on.
If this truly has not been the default since 1.4, then the fact that
the previous build worked for people
like Ian using the proprietary 1.6 JDK is very odd.

Personally, I've never had a copy of 1.4.2 or any of the other
proprietary JDKs on my system, and have thus only built JikesRVM using
OpenJDK builds.
It is of course possible that there is something in the tree from older JDKs.

However, from working with the langtools code myself, I do remember
there being two versions of javah.
Ant is presumably calling javah programmatically (i.e. via com.sun
rather than via the command line version)
and so could of course be using the old API even in 1.5 and above.
This suggests that either OpenJDK6
produces the new version even from the old API, or that later versions
of Ant have switched to using the
newer API.

Ian, which version of Ant do you use to build?

Thanks,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8


From doko at ubuntu.com  Mon Apr 28 04:12:19 2008
From: doko at ubuntu.com (Matthias Klose)
Date: Mon, 28 Apr 2008 13:12:19 +0200
Subject: another review of copyright/license stuff in openjdk-b09
In-Reply-To: <481598C2.9020308@ubuntu.com>
References: <480DD868.2060003@ubuntu.com> <481598C2.9020308@ubuntu.com>
Message-ID: <4815B113.6080102@ubuntu.com>

now tracking this at
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=138


From gnu_andrew at member.fsf.org  Mon Apr 28 08:34:36 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 28 Apr 2008 16:34:36 +0100
Subject: javah output file naming weirdness
In-Reply-To: <481591C8.7070507@gmail.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
	<481514FF.9030704@sun.com>
	<17c6771e0804280301rcc82bddt560f95308d36f4f1@mail.gmail.com>
	<481591C8.7070507@gmail.com>
Message-ID: <17c6771e0804280834k494ea31u2b59fe1d052e1595@mail.gmail.com>

2008/4/28 Ian Rogers <rogers.email at gmail.com>:
> Andrew John Hughes wrote:
>
> > Ian, which version of Ant do you use to build?
> >
> > Thanks,
> >
> >
>
>  I'm currently using ant 1.7.0 although I've used many 1.6 ant releases to
> build Jikes RVM. Our regression machine set up uses ant version 1.6.5.
>
>  Regards,
>  Ian
>
>
>  --
>  Third International Workshop on Implementation, Compilation, Optimization
> of Object-Oriented Languages, Programs and Systems (ICOOOLPS 2008)
>  Submissions/Notification/Conference: May 4th/May 19th/July 7th
>  Paphos (Cyprus) http://icoolps.loria.fr
>

Ok that's the same as me... curiouser and curiouser...
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8


From Alan.Bateman at Sun.COM  Mon Apr 28 08:33:58 2008
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 28 Apr 2008 16:33:58 +0100
Subject: javah output file naming weirdness
In-Reply-To: <4814F00D.8020900@gmail.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
	<481514FF.9030704@sun.com> <4814F00D.8020900@gmail.com>
Message-ID: <4815EE66.9090302@sun.com>

Ian Rogers wrote:
> :
> it's a requirement that the Jikes RVM is built with at least Java 5.0 
> due to wide spread use of generics and annotations in the code base. I 
> personally use Java 6 to build Jikes RVM (on systems with neither Java 
> 1.4.2 or Java 5.0 installed). The only time I've heard of a problem 
> with javah is Andrew when using Open JDK 6. We could have been fluking 
> things before.
Perhaps my suggestion that this might be an old javah vs. new javah 
issue is a red herring but, just for pig iron, I created a class 
org.jikesvvm.scheduler.greenthreads.VM_Process and ran javac + javah 
with each of openjdk (7), Sun's jdk5, and Sun's jdk6. All generate 
org_jikesvvm_scheduler_greenthreads_VM_Process.h. This has me curious as 
to how org_jikesvvm_scheduler_greenthreads_VM_0005fProcess.h is 
generated in your environment since you are using "Java 6". Is this 
Sun's jdk6?

-Alan.




From aph at redhat.com  Mon Apr 28 08:41:30 2008
From: aph at redhat.com (Andrew Haley)
Date: Mon, 28 Apr 2008 16:41:30 +0100
Subject: javah output file naming weirdness
In-Reply-To: <4815EE66.9090302@sun.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>	<481514FF.9030704@sun.com>
	<4814F00D.8020900@gmail.com> <4815EE66.9090302@sun.com>
Message-ID: <4815F02A.2030309@redhat.com>

Alan Bateman wrote:
> Ian Rogers wrote:
>> :
>> it's a requirement that the Jikes RVM is built with at least Java 5.0
>> due to wide spread use of generics and annotations in the code base. I
>> personally use Java 6 to build Jikes RVM (on systems with neither Java
>> 1.4.2 or Java 5.0 installed). The only time I've heard of a problem
>> with javah is Andrew when using Open JDK 6. We could have been fluking
>> things before.
> Perhaps my suggestion that this might be an old javah vs. new javah
> issue is a red herring but, just for pig iron, I created a class
> org.jikesvvm.scheduler.greenthreads.VM_Process and ran javac + javah
> with each of openjdk (7), Sun's jdk5, and Sun's jdk6. All generate
> org_jikesvvm_scheduler_greenthreads_VM_Process.h. This has me curious as
> to how org_jikesvvm_scheduler_greenthreads_VM_0005fProcess.h is
> generated in your environment since you are using "Java 6". Is this
> Sun's jdk6?

Something to do with LANG in the environment?

Andrew.


From gnu_andrew at member.fsf.org  Mon Apr 28 08:42:21 2008
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 28 Apr 2008 16:42:21 +0100
Subject: javah output file naming weirdness
In-Reply-To: <4815EE66.9090302@sun.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>
	<481514FF.9030704@sun.com> <4814F00D.8020900@gmail.com>
	<4815EE66.9090302@sun.com>
Message-ID: <17c6771e0804280842v4e74e585p2b06c7b7ad951e90@mail.gmail.com>

2008/4/28 Alan Bateman <Alan.Bateman at sun.com>:
> Ian Rogers wrote:
>
> > :
> > it's a requirement that the Jikes RVM is built with at least Java 5.0 due
> to wide spread use of generics and annotations in the code base. I
> personally use Java 6 to build Jikes RVM (on systems with neither Java 1.4.2
> or Java 5.0 installed). The only time I've heard of a problem with javah is
> Andrew when using Open JDK 6. We could have been fluking things before.
> >
>  Perhaps my suggestion that this might be an old javah vs. new javah issue
> is a red herring but, just for pig iron, I created a class
> org.jikesvvm.scheduler.greenthreads.VM_Process and ran javac + javah with
> each of openjdk (7), Sun's jdk5, and Sun's jdk6. All generate
> org_jikesvvm_scheduler_greenthreads_VM_Process.h. This has me curious as to
> how org_jikesvvm_scheduler_greenthreads_VM_0005fProcess.h is generated in
> your environment since you are using "Java 6". Is this Sun's jdk6?
>
>  -Alan.
>
>
>

Alan,

Good to know I'm not the only one seeing the lack of an 0005f.  Ian,
can you shed any more light on this?

Thanks,
-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8


From rogers.email at gmail.com  Mon Apr 28 01:58:48 2008
From: rogers.email at gmail.com (Ian Rogers)
Date: Mon, 28 Apr 2008 09:58:48 +0100
Subject: javah output file naming weirdness
In-Reply-To: <17c6771e0804280301rcc82bddt560f95308d36f4f1@mail.gmail.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>	
	<481514FF.9030704@sun.com>
	<17c6771e0804280301rcc82bddt560f95308d36f4f1@mail.gmail.com>
Message-ID: <481591C8.7070507@gmail.com>

Andrew John Hughes wrote:
> Ian, which version of Ant do you use to build?
>
> Thanks,
>   

I'm currently using ant 1.7.0 although I've used many 1.6 ant releases 
to build Jikes RVM. Our regression machine set up uses ant version 1.6.5.

Regards,
Ian
-- 
Third International Workshop on Implementation, Compilation, 
Optimization of Object-Oriented Languages, Programs and Systems 
(ICOOOLPS 2008)
Submissions/Notification/Conference: May 4th/May 19th/July 7th
Paphos (Cyprus) http://icoolps.loria.fr


From rogers.email at gmail.com  Mon Apr 28 09:10:44 2008
From: rogers.email at gmail.com (Ian Rogers)
Date: Mon, 28 Apr 2008 11:10:44 -0500
Subject: javah output file naming weirdness
In-Reply-To: <17c6771e0804280842v4e74e585p2b06c7b7ad951e90@mail.gmail.com>
References: <17c6771e0804270821h4b8d597h4a12d4520e50059e@mail.gmail.com>	
	<481514FF.9030704@sun.com> <4814F00D.8020900@gmail.com>	
	<4815EE66.9090302@sun.com>
	<17c6771e0804280842v4e74e585p2b06c7b7ad951e90@mail.gmail.com>
Message-ID: <4815F704.1090908@gmail.com>

Andrew John Hughes wrote:
> 2008/4/28 Alan Bateman <Alan.Bateman at sun.com>:
>   
>> Ian Rogers wrote:
>>
>>     
>>> :
>>> it's a requirement that the Jikes RVM is built with at least Java 5.0 due
>>>       
>> to wide spread use of generics and annotations in the code base. I
>> personally use Java 6 to build Jikes RVM (on systems with neither Java 1.4.2
>> or Java 5.0 installed). The only time I've heard of a problem with javah is
>> Andrew when using Open JDK 6. We could have been fluking things before.
>>     
>>  Perhaps my suggestion that this might be an old javah vs. new javah issue
>> is a red herring but, just for pig iron, I created a class
>> org.jikesvvm.scheduler.greenthreads.VM_Process and ran javac + javah with
>> each of openjdk (7), Sun's jdk5, and Sun's jdk6. All generate
>> org_jikesvvm_scheduler_greenthreads_VM_Process.h. This has me curious as to
>> how org_jikesvvm_scheduler_greenthreads_VM_0005fProcess.h is generated in
>> your environment since you are using "Java 6". Is this Sun's jdk6?
>>
>>  -Alan.
>>
>>
>>
>>     
>
> Alan,
>
> Good to know I'm not the only one seeing the lack of an 0005f.  Ian,
> can you shed any more light on this?
>
> Thanks,
>   

My $LANG is en_GB, I've been using Sun JDK 5 and 6. At some points also 
JRockit and IBM's JDKs. For our regression machines we must use IBM's 
JDK on AIX machines. The $LANG on the main regression machines is 
en_AU.UTF-8 .

Repeating Alan's test (javah -d . -jni 
org.jikesrvm.scheduler.greenthreads.VM_Process) causes the creation of 
org_jikesrvm_scheduler_greenthreads_VM_Process.h for me - no 0005f. 
javah -version is "1.6.0_04". Andrew, does this mean your ant behaviour 
is the cause?

Thanks,
Ian
--
Third International Workshop on Implementation, Compilation, 
Optimization of Object-Oriented Languages, Programs and Systems 
(ICOOOLPS 2008)
Submissions/Notification/Conference: May 4th/May 19th/July 7th
Paphos (Cyprus) http://icoolps.loria.fr