Resat SABIQ

icon location IDF, France icon location Full-stack polyvalent developper

Results 13 comments of Resat SABIQ

Provide a JPA-based ORM implementation

Other options for providing an ORM implementation could be the following: 2. http://hibernate.org/ogm/ 3. https://github.com/Impetus/Kundera If this is something that's going to be considered, a mention of an approximate timeframe...

Provide a JPA-based ORM implementation

Considering various possibilities, I've made the subject line a bit more specific. P.S. Perhaps other possibilities could be considered separately. For instance, a JDO-based ORM implementation as part of, e.g.,...

Add a sub-section on usage of zero-width space

FYI, I separated the suggestions into 2 PRs: 1. #644: related to first 2 examples in the OP 2. #645: related to the last example in the OP (includes item...

[corejs3] Avoid injecting `"".split` polyfill when it's not necessary

I think this is a move in the right direction. (Perhaps as phase 2,) I'd like to see calls like the following supported and covered by test(s) as well, because...

[corejs3] Avoid injecting `"".split` polyfill when it's not necessary

> Note that the polyfill is not for the "this", it's for the argument. In any case, it would be nice if cases like those mentioned in the OP under...

JsonParser should be capable of parsing keys not surrounded by "

The above example currently results in: javax.json.stream.JsonParsingException: Invalid token=NUMBER at (line no=1, column no=14, offset=13). Expected tokens are: [STRING] at org.glassfish.json.JsonParserImpl.parsingException(JsonParserImpl.java:238) at org.glassfish.json.JsonParserImpl.access$1200(JsonParserImpl.java:61) at org.glassfish.json.JsonParserImpl$ObjectContext.getNextEvent(JsonParserImpl.java:291) at org.glassfish.json.JsonParserImpl$StateIterator.next(JsonParserImpl.java:172) at org.glassfish.json.JsonParserImpl.next(JsonParserImpl.java:149) at...

JsonParser should be capable of parsing keys not surrounded by "

One can achieve equivalent shorter JSON using an array of numbers instead, but if the usecase requires only a AbstractMap.SimpleImmutableEntry, then it's better to use that rather than an array...

JsonParser should be capable of parsing keys not surrounded by "

Of course the same should be applicable to the writing side: JSON should be optimized there first.

JsonParser should be capable of parsing keys not surrounded by "

The approach i like currently requires custom `MessageBodyWriter` & `MessageBodyReader`. But i think this optimization should be the default behavior. P.S. The current implementation is not optimized enough with regards...

JsonParser should be capable of parsing keys not surrounded by "

Good point: this enhancement in jsonp would require & depend on a similar enhancement in JSON.parse(...). So i guess this would be a long-term thing, if it ever happens. >...