Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 02 Jun 2006 13:33:10 -0700
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: java.util.concurrent
In-reply-to: <AA4855A9-5468-4676-AB39-ECC58587262A@bea.com>
Sender: Craig.Russell@Sun.COM
To: open-jpa-dev@incubator.apache.org
Message-id: <AA898A69-3BD1-4EE5-85EA-C7D1C3A07E96@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-112--825500831; micalg=sha1
References: <C8A725B0-2691-45E9-B3C8-FDA810B554C9@bea.com>
 <2A86AFBC-206D-4D7C-BF94-753B09EDCB9C@SUN.com>
 <9FDA7083-DDA3-41D7-BD07-8B5B34BB4A91@mac.com> <4480983C.2070105@pobox.com>
 <AA4855A9-5468-4676-AB39-ECC58587262A@bea.com>

--Apple-Mail-112--825500831
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Jun 2, 2006, at 1:22 PM, Abe White wrote:

>> But not everyone favors it.  For a project like this, where there are
>> multiple people working on things, having the imports called out  
>> really
>> helps.
>>
>> What's the downside?
>
> Just that it's verbose and makes writing imports by hand take  
> longer.  But I don't feel strongly about it.  I'm find with  
> explicit imports if that's the consensus.
>
I've already given my rationale why I like explicit imports.
>
>> I'm a "before dot" man myself so it's clear from just looking at the
>> beginning of the line it's a method/field.
>
> I'm an after dot person, but again I'm fine with whatever,  
> including not enforcing any particular policy on this.

I don't feel strongly enough to require a standard.
>
>> How about just configuring IDEA/Eclipse to do it right, and fixing
>> things as we go along?
>
> I like the idea of using an IDE to fix everything.  I don't use an  
> IDE myself, so I don't know whether it can make the necessary  
> fixes.  Here's a list of changes necessary to get SolarMetric code  
> looking more like the standards we've outlined:
> - Change to explicit imports.

yes

> - Move opening brace to same line.

yes

> - Move up "else" and "catch" to same line as previous closing brace.

yes

> - Move up "extends" and "implements" to same line as class  
> declaration.

yes

> - Move up "throws" to same line as method declaration.

yes

> - Remove spaces before opening parens on method calls.

don't really care

> - Change tabs to spaces.

yes

> - Remove extraneous spaces from field declarations (we tend to  
> align declarations with tabs, so converting the tabs to spaces make  
> sit look horrible... plus I'd like to just stop aligning  
> declarations altogether anyway).

don't care about extraneous spaces or aligning declarations, but  
would like to remove tabs

> - Remove extraneous spaces from Javadoc (again, we use tabs to  
> align things a lot).

don't care

> - Collapse double-blank lines into a single blank line (we use 2  
> blank lines for block separators a lot).

don't care

> - Make above changes without creating lines over 80 chars.

yes
>
> My formatter does all the above except the explicit imports, and it  
> sometimes create lines over 80 chars when moving up extends/ 
> implements/throws lines.  Not mentioned on the list: it's also able  
> to take a previously-continued line and turn it back into a single  
> line if the above changes cause the single line to now be <= 80 chars.
>
> If IDE's can't do that, then perhaps a hybrid approach where we use  
> my formatter to get everything most of the way there, then use an  
> IDE to get the explicit imports as we go along.  This also has the  
> advantage of getting everything into an almost-there style in one  
> fell swoop, rather than having two totally different styles until  
> someone with an IDE opens all the files eventually.
>
> Note that until we can get everything necessary from Kodo into  
> OpenJPA, we probably don't want to mess with formatting, because we  
> have to be able to merge changes back and forth between the  
> codebases easily.

I like the idea of a massive change early in the cycle (before the  
initial checkin is fine, or sometime shortly thereafter). For the  
first week or so, I'm mostly going to be reading the code anyway.

Craig

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


--Apple-Mail-112--825500831
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICEB7Y7fLHmKoeHTUdbtYrvpAwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxNTIxNDc0NFoXDTA2MTIxNTIxNDc0
NFowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMXXgEAm88nu8cFbxXSWqTq+GaYpCx/0QSom
8kBbVxpJIURuO4ErLDupeXu6y9+5e7ZKLbeSQE5xbfYPcQR/IhqmYKy5YqRcuzPXREBj2zKEkZph
pNXWpHgMdx9W8dq0Cu2i9Ux/S6c2MuEHrP6gfGGll+b/mzLoO280QHTuE4pcpKntRnwZdGxQ/5l8
IL+eLP+jpJAbYW9C+KNKofZtS6V6R0uzlqTOsEdZvwxZQ4mmPgHoz1+Gjwme/PC5sKvF09MaJDiI
pj9SvZ4CTCgcDZV78J086YwlVbMC0VQotjhu1p42lr8CS33IXLz3OWNrDETCAepah/Dgw2ZZApQ9
9L0CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEEBQADgYEAKdIkgAWCg2Bi7ocnstfJA4iymTRI2/L4oQx9zvllM9bNJ2cR
cecJIx3HuoHbhPvemh1GExEPgHU+dXSxDmD0BEmPnhSReKCURyslnbMphPZ5kR6USzQFrRa+v0ii
J+SBO9VQYTQWT+xEjmRLM76MfkBFw3IOC9CUkRoYZ88pOoUwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEB7Y7fLHmKoeHTUdbtYrvpAwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNjAyMjAzMzExWjAjBgkqhkiG9w0B
CQQxFgQUKy/Ew6YYYY78EeuMURm0ySZnmsAwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe2O3yx5iqHh01HW7WK76QMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe
2O3yx5iqHh01HW7WK76QMA0GCSqGSIb3DQEBAQUABIIBAGd7ZFt1/iI74He4Gp98cjNXgx7n6JLx
fSTFT26l/luYzX+5nmR7yB8V22GxxS2w4lfzHWwyYMUw7JlM+bbOxBx1CuMukKGtCe5yYHORRD/Y
lb+x2PRQKiKnhQYjA7bfkmlhFpbp6SF8reZpzFZ9TR42hdMBEpQzsUX2QGyB9qXH5wsYaQjYh5LJ
kHdkuzXZcYcam7u0ZhWm0ILa5fqxeW74+HyUtHZBuRzdOhFEfjP5+rzgtGiNzGomsgmv8Wu7DW2p
qJc03qmLwrCEyBRCRMX8Ayjq+7fr5cR3xwZ0uR9t8JgBYf18l4vlNDfGpW0QgO3YHNFgntZIjwB6
IUN/z5oAAAAAAAA=

--Apple-Mail-112--825500831--