[jira] [Comment Edited] (BCEL-276) LocalVariableTypeTable is not updated.

2017-01-12 Thread Sam Yoon (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821160#comment-15821160
 ] 

Sam Yoon edited comment on BCEL-276 at 1/12/17 2:58 PM:


[~britter] I was applied a patch suggested by [~markro] and push to my branch.
Thanks for you advice.


was (Author: samyoon):
I was applied a patch suggested by [~markro] and push to my branch.
Thanks for you advice.

> LocalVariableTypeTable is not updated. 
> ---
>
> Key: BCEL-276
> URL: https://issues.apache.org/jira/browse/BCEL-276
> Project: Commons BCEL
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Sam Yoon
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 6.1
>
> Attachments: LocalVariable.mark.diff, LocalVariableGen.mark.diff, 
> LocalVariableTypeTableTest.java, MethodGen.diff, MethodGen.mark.diff, 
> SimpleClassHasMethodIncludeGenericArgument.java
>
>
> If a method for BCI have at least one generic type of argument JVM throw 
> java.lang.ClassFormatError due to not updated LocalVariableTable.
> I know there is workaround as call removeLocalVariables method.
> But I think it's better that BCEL can stay proper LocalVariableTable.
> I'm also pull test case can reproduce error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821169#comment-15821169
 ] 

ASF GitHub Bot commented on COMMONSRDF-51:
--

GitHub user stain opened a pull request:

https://github.com/apache/commons-rdf/pull/30

COMMONSRDF-51 language tags compared lower case

This fixes 
[COMMONSRDF-51](https://issues.apache.org/jira/browse/COMMONSRDF-51) - at least 
from `Literal.equals()` and `Literal.hashCode()`

Further test might be needed to verify consistent behaviour in `Graph` and 
`Dataset` if underlying framework does not correctly do langtag comparison in 
lower case (e.g. Turkish locale problem).

Please comment on the fixes and the suggested updated javadoc:

* 
[Literal.equals(Object)](http://stain.github.io/commons-rdf/COMMONSRDF-51/org/apache/commons/rdf/api/Literal.html#equals-java.lang.Object-)
* 
[Literal.hashCode()](http://stain.github.io/commons-rdf/COMMONSRDF-51/org/apache/commons/rdf/api/Literal.html#hashCode--)
* 
[Literal.getLanguageTag()](http://stain.github.io/commons-rdf/COMMONSRDF-51/org/apache/commons/rdf/api/Literal.html#getLanguageTag--)

For code improvements of this PR, feel free to push to the 
`COMMONSRDF-51-langtag-lcase` branch at 
https://git-wip-us.apache.org/repos/asf/commons-rdf.git or use the "Start 
review" mechanism in GitHub.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/commons-rdf COMMONSRDF-51-langtag-lcase

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-rdf/pull/30.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #30


commit 3064d219606cbe42c0150d81dbf6cdbc74bf7491
Author: Stian Soiland-Reyes 
Date:   2017-01-12T14:51:26Z

COMMONSRDF-51: compare language tags in lower case




> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread Stian Soiland-Reyes (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821170#comment-15821170
 ] 

Stian Soiland-Reyes commented on COMMONSRDF-51:
---

Pull request ready for review:

https://github.com/apache/commons-rdf/pull/30

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (BCEL-276) LocalVariableTypeTable is not updated.

2017-01-12 Thread Sam Yoon (JIRA) 

[ 
https://issues.apache.org/jira/browse/BCEL-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821160#comment-15821160
 ] 

Sam Yoon commented on BCEL-276:
---

I was applied a patch suggested by [~markro] and push to my branch.
Thanks for you advice.

> LocalVariableTypeTable is not updated. 
> ---
>
> Key: BCEL-276
> URL: https://issues.apache.org/jira/browse/BCEL-276
> Project: Commons BCEL
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Sam Yoon
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 6.1
>
> Attachments: LocalVariable.mark.diff, LocalVariableGen.mark.diff, 
> LocalVariableTypeTableTest.java, MethodGen.diff, MethodGen.mark.diff, 
> SimpleClassHasMethodIncludeGenericArgument.java
>
>
> If a method for BCI have at least one generic type of argument JVM throw 
> java.lang.ClassFormatError due to not updated LocalVariableTable.
> I know there is workaround as call removeLocalVariables method.
> But I think it's better that BCEL can stay proper LocalVariableTable.
> I'm also pull test case can reproduce error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-58) All uppercase methods?

2017-01-12 Thread Gilles (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821092#comment-15821092
 ] 

Gilles commented on TEXT-58:


Sorry, I was referring to 
[EntityArrays.java|https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/translate/EntityArrays.java].

bq. there's virtually no point in ever declaring a static final array.

It protects against assignment (but not change of elements).


> All uppercase methods?
> --
>
> Key: TEXT-58
> URL: https://issues.apache.org/jira/browse/TEXT-58
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>Priority: Trivial
>  Labels: api, convention, standard
> Fix For: 1.0
>
>
> Class {{o.a.c.text.translate.EntityArrays}} contains methods names with all 
> uppercase letters (and underscores).
> I understand that they create copies of _static_ constants (although even 
> that is not true since they return arrays!), but are you sure you want to 
> release a new component that does not follow the usual convention?
> I understand these comes from LANG but isn't it the right time to fix the API?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TEXT-58) All uppercase methods?

2017-01-12 Thread Gilles (JIRA) 

 [ 
https://issues.apache.org/jira/browse/TEXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles updated TEXT-58:
---
Description: 
Class {{o.a.c.text.translate.EntityArrays}} contains methods names with all 
uppercase letters (and underscores).

I understand that they create copies of _static_ constants (although even that 
is not true since they return arrays!), but are you sure you want to release a 
new component that does not follow the usual convention?

I understand these comes from LANG but isn't it the right time to fix the API?


  was:
Class {{o.a.c.text.translate.JavaUnicodeEscaper}} contains methods names with 
all uppercase letters (and underscores).

I understand that they create copies of _static_ constants (although even that 
is not true since they return arrays!), but are you sure you want to release a 
new component that does not follow the usual convention?

I understand these comes from LANG but isn't it the right time to fix the API?



> All uppercase methods?
> --
>
> Key: TEXT-58
> URL: https://issues.apache.org/jira/browse/TEXT-58
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>Priority: Trivial
>  Labels: api, convention, standard
> Fix For: 1.0
>
>
> Class {{o.a.c.text.translate.EntityArrays}} contains methods names with all 
> uppercase letters (and underscores).
> I understand that they create copies of _static_ constants (although even 
> that is not true since they return arrays!), but are you sure you want to 
> release a new component that does not follow the usual convention?
> I understand these comes from LANG but isn't it the right time to fix the API?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TEXT-58) All uppercase methods?

2017-01-12 Thread Rob Tompkins (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15821005#comment-15821005
 ] 

Rob Tompkins commented on TEXT-58:
--

Are you referencing this array? 
https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/translate/CharSequenceTranslator.java#L33

If so your point is quite valuable because there's virtually no point in ever 
declaring a static final array.

That said, because it's scope is default do you think that it matters? (I 
suppose a consumer could declare the same package name and use it).

> All uppercase methods?
> --
>
> Key: TEXT-58
> URL: https://issues.apache.org/jira/browse/TEXT-58
> Project: Commons Text
>  Issue Type: Improvement
>Reporter: Gilles
>Priority: Trivial
>  Labels: api, convention, standard
> Fix For: 1.0
>
>
> Class {{o.a.c.text.translate.JavaUnicodeEscaper}} contains methods names with 
> all uppercase letters (and underscores).
> I understand that they create copies of _static_ constants (although even 
> that is not true since they return arrays!), but are you sure you want to 
> release a new component that does not follow the usual convention?
> I understand these comes from LANG but isn't it the right time to fix the API?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820850#comment-15820850
 ] 

Andy Seaborne commented on COMMONSRDF-51:
-

This is confusing the lexical representation and the value space.

See the text:

[[
Two literals are term-equal ...
Thus, two literals can have the same value without being the same RDF term.
]]

I see no confusion of the character by character text - it is defining "same 
term", not "same value" which is what a case-insensitive lang tag comparison of 
use for as covered by the second part.

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread Andy Seaborne (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820846#comment-15820846
 ] 

Andy Seaborne commented on COMMONSRDF-51:
-

"a-z and A-Z are permitted" -- not permitted, that is the range of allowed, no 
more.  Only ASCII characters are in a language tag.  Turtle does not allow any 
other characters.

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread Stian Soiland-Reyes (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820820#comment-15820820
 ] 

Stian Soiland-Reyes commented on COMMONSRDF-51:
---

[BCP47 section 2.1.1|https://tools.ietf.org/html/bcp47#section-2.1.1] also 
clearly states case has no meaning, just convention. Therefore we should 
probably try to preserve the casing, but not use it for comparison:

{quote}
   At all times, language tags and their subtags, including private use
   and extensions, are to be treated as case insensitive: there exist
   conventions for the capitalization of some of the subtags, but these
   MUST NOT be taken to carry meaning.

   Thus, the tag "mn-Cyrl-MN" is not distinct from "MN-cYRL-mn" or "mN-
   cYrL-Mn" (or any other combination), and each of these variations
   conveys the same meaning: Mongolian written in the Cyrillic script as
   used in Mongolia.

   The ABNF syntax also does not distinguish between upper- and
   lowercase: the uppercase US-ASCII letters in the range 'A' through
   'Z' are always considered equivalent and mapped directly to their US-
   ASCII lowercase equivalents in the range 'a' through 'z'.  So the tag
   "I-AMI" is considered equivalent to that value "i-ami" in the
   'irregular' production.
{quote}

I'll push the branch as a pull request and make bugs for the Turkish issue 
upstream.


> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread Stian Soiland-Reyes (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820814#comment-15820814
 ] 

Stian Soiland-Reyes commented on COMMONSRDF-51:
---

Got one reply already on 
[public-rdf-comments|http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/thread.html],
 from [Richard 
Cyganiak|http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/0005.html]:

{quote}
RDF 2004 forced the language tag to be lower-cased in the abstract syntax. 
Implementations of RDF 2004 often did not do that, but retained the case when 
storing or transforming RDF, while still treating @en and @EN as equal. My 
recollection is that we wanted to change the language of the spec to make this 
behaviour legal. Unfortunately it seems the language came out less clear than 
it should be. I do not think that there was any intention to make @en and @EN 
not equal.
{quote}


> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case

2017-01-12 Thread Stian Soiland-Reyes (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820811#comment-15820811
 ] 

Stian Soiland-Reyes commented on COMMONSRDF-51:
---

Yes, so both a-z and A-Z are permitted and valid in Turtle etc. However the 
spec also says (and here is the ambiguity against "character by character"):

> Lexical representations of language tags may be converted to lower case. 

and :

> The value space of language tags is always in lower case.

then doing a case-sensitive comparison sounds fragile, e.g. impl1 may do 
lowercase (e.g. Jena) and impl2 leave them as-is (e.g. JSON-LD) - and then that 
would break calls like graph.contains().

So even if my [public-rdf-comments 
question|http://lists.w3.org/Archives/Public/public-rdf-comments/2017Jan/thread.html]
 concludes with case sensitivity, we would probably want to make Commons RDF do 
its best for lowercase comparisons anyway for consistent interoperability. In 
that case perhaps we should add tests also to the graph and datasets to ensure 
any "call-through" don't break literal equivalence.

> RDF-1.1 specifies that language tags need to be compared using lower-case
> -
>
> Key: COMMONSRDF-51
> URL: https://issues.apache.org/jira/browse/COMMONSRDF-51
> Project: Apache Commons RDF
>  Issue Type: Bug
>  Components: api
>Affects Versions: 0.3.0
>Reporter: Peter Ansell
>Assignee: Stian Soiland-Reyes
>
> The [RDF-1.1 specification states that the [value space of Literal language 
> tags is 
> lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which 
> does not conflict with the case-insensitive specification in BCP47. The 
> Literal.equals and Literal.hashCode API contracts should specify that 
> language tags must be compared using lowercase, even if they are otherwise 
> stored and returned as upper-case by getLanguageTag. The API currently has 
> incorrect language by saying "character-by-character" for language tag 
> comparisons, as that implies case-sensitive comparisons are used.
> The lowercasing must also be done using a locale that is consistent (known 
> example where lowercase and uppercase do not roundtrip as expected for 
> US-ASCII characters is Turkish [1]), so I would recommend actually stating 
> that .toLowerCase(Locale.ENGLISH) is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)