search

byeblogs / json-simple

Automatically exported from code.google.com/p/json-simple
Apache License 2.0
0 stars 0 forks source link

Raw types when inheriting from HashMap, instead of <Object,Object> #15

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This implementation choice makes it impossible to use json-simple with Scala 
without modification. However, everything works fine when updating the 
JSONObject declaration to the following:

public class JSONObject extends HashMap<Object, Object> implements 
Map<Object, Object>, JSONAware, JSONStreamAware{

This is also probably a Scala bug, but people seemed to think it is a better 
practice to use typed HashMap instead of raw.

See <http://old.nabble.com/Complicated-type-error-with-
org.json.simple.JSONObject:put-td26716918.html> for full details.

Cheers,

 -- Sébastien

Original issue reported on code.google.com by sebastie...@gmail.com on 15 Dec 2009 at 1:20

GoogleCodeExporter commented 9 years ago 
One feature of JSON.simple is to be compatible with JDK1.2 and later (both 
source
level and binary level, so it supports almost all of JDKs if not all), thus
JSON.simple doesn't use generic feature from JDK1.5 directly, but it does 
support all
of Map and List implementations with
JSONValue.toJSONString()/JSONValue.writeJSONString(). 

As a result, if an application/library can not use JSON.simple, it may be a 
build or
configuration issue of that application/library.

Thanks.

Original comment by fangyid...@gmail.com on 16 Dec 2009 at 8:41

GoogleCodeExporter commented 9 years ago 
I followed the link you provided, maybe you can type something like to make it 
work:

scala> o.put("a",new Integer(1))

Original comment by fangyid...@gmail.com on 16 Dec 2009 at 1:22

GoogleCodeExporter commented 9 years ago 
Unfortunately no:

scala> obj.put("a",new Integer(1))
<console>:8: error: overloaded method value put with alternatives (K,V)V <and> 
((K
with K,_20)_20) forSome { type _20 >: V with V } cannot be applied to
(java.lang.String,java.lang.Integer)
       obj.put("a",new Integer(1))

Original comment by marco.la...@gmail.com on 16 Dec 2009 at 1:32

GoogleCodeExporter commented 9 years ago 
The following should work:

scala> val o = new java.util.HashMap[String, Int]()
o: java.util.HashMap[String,Int] = {}

scala> o.put("a",1)
res5: Int = 0

scala> org.json.simple.JSONValue.toJSONString(o)
res6: java.lang.String = {"a":1}

Original comment by fangyid...@gmail.com on 16 Dec 2009 at 3:51

GoogleCodeExporter commented 9 years ago 
Thanks a lot for the tip !

Original comment by sebastie...@gmail.com on 16 Dec 2009 at 5:47

GoogleCodeExporter commented 9 years ago 
Is there any merit to releasing version 2.0 of this library to support language
improvements like generics and strongly typed collections?

Since JDK 1.4 is now reaching end of life, these types of updates would be 
really
useful for EE applications built on Java EE 5 where Javascript and Java are
responsible for data exchange.

Original comment by owen.far...@gmail.com on 5 Mar 2010 at 6:14

GoogleCodeExporter commented 9 years ago 
Thank you Owen for your suggestion, I'll re-consider supporting of JDK2. The 
initial
intention is to make it compatible with ALL version of JDK as well as J2ME.

Original comment by fangyid...@gmail.com on 8 Mar 2010 at 5:52

GoogleCodeExporter commented 9 years ago

Original comment by fangyid...@gmail.com on 29 Nov 2011 at 3:26

GoogleCodeExporter commented 9 years ago 
My two cents in favour of migrating to generics: compiling a java project 
(which uses json-simple) with javac's -Xlint option results into dozens of 
"[unchecked]" warnings. Thanks.

Original comment by dvdk...@gmail.com on 4 Dec 2012 at 3:09

GoogleCodeExporter commented 9 years ago 
Until the library is updated to support generics this could be a case where 
@SuppressWarnings("unchecked") makes sense.

Original comment by Ryan.Slo...@gmail.com on 2 May 2013 at 6:48

GoogleCodeExporter commented 9 years ago 
Another vote to leave ancient history behind and use generics.

Original comment by fschm...@gmail.com on 1 Jul 2013 at 10:52

GoogleCodeExporter commented 9 years ago 
Please, stop supporting old version of Java and start supporting generics!

Original comment by petr.pan...@gmail.com on 17 Oct 2013 at 2:32

GoogleCodeExporter commented 9 years ago 
One more vote for supporting generics; trying to iterate over the object in an 
idiomatic way like so:

   for (Map.Entry entry : jsonObject.entrySet()) { /* ... */ }

will lead to compile errors, because the compiler is seeing a Set of Objects 
instead of a set to Map.Entry instances.
Looking at 
http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-20
14/ slide 6: only 2% are still on Java 5, Java4 is not even mentioned anymore.

Original comment by ton.van....@gmail.com on 6 Jun 2014 at 10:22

GoogleCodeExporter commented 9 years ago 
I have a best solution. Instead of this lib, use Gson.
Gson has generics and you need not try to catch an exception on every single 
interface method invocation.

Original comment by hugona...@gmail.com on 6 Jun 2014 at 1:13