Bugzilla – Full Text Bug Listing
| Summary: | org.json bundle doesn't support enumerations as compiled by 1.2 JDK | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] Orbit | Reporter: | Dzmitry [zmicer] Harachka <zmicer.harachka> | ||||||||||||
| Component: | bundles | Assignee: | Austin Riddle <austin.riddle> | ||||||||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P3 | CC: | austin.riddle, david_williams, john.arthorne, mtaal, Olivier_Thomann | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | --- | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Windows XP | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Dzmitry [zmicer] Harachka
Created attachment 180461 [details]
org.json updated bundle without digest
Created attachment 180462 [details]
org.json sources bundle
Seems to be original json author supports versioning by datestamp: org.json.JSONObject * @author JSON.org * @version 2010-05-17 So may be it has a sense to add this stamp in some way to the version of bundle. See also bug 326179. Austin, I've assigned you as owner since you are listed as contact. Can you address? (In reply to comment #4) > See also bug 326179. > > Austin, I've assigned you as owner since you are listed as contact. Can you > address? I will address, but not until next week. Sorry, been swamped. at our texo dev environment locally we use updated versions of these files. So do not be in a hurry. (In reply to comment #6) > at our texo dev environment locally we use updated versions of these files. So > do not be in a hurry. Hi Dzmitry, Thank you for opening this ticket and submitting your updated bundle. The reason that the enum in BookCategory failed to serialize is because enum was defined in Java 1.5 and is not supported under 1.4. Unfortunately, the org.json compiler settings need to stay at 1.4 because of the other projects that depend on it, which means that enum cannot be supported in this version of JSON. However, in the future that may change. Thanks again. Hi, Austin! Is not it possible to have several versions of json library at orbit project? If we use enums at texo project, then anyway we need somewhen another version of json not only at our dev. environment but also for tests, or for other developers and users. Hi Austin, Yes, isn't it possible to have multiple versions of the json plugin? gr. Martin David, How do other Orbit bundles handle these kind of compiler setting differences? Via multiple versions? (In reply to comment #10) > David, > > How do other Orbit bundles handle these kind of compiler setting differences? > Via multiple versions? This sounds like a first. I'll confess I don't have a good grasp of the technical issues you are discussing, but on the surface, it sounds like you are trying to "use more" than what is provided. Is this about using enums? Or using annotations? Other things I find confusing: Bundle-RequiredExecutionEnvironment: CDC-1.1/Foundation-1.1,J2SE-1.2 is mentioned as current setting, but elsewhere its said "1.4" is the required setting. (And, you've said you want it to be 1.5). Can you clarify the issue about 1.2 vs. 1.4? Also, is this that one (and only) bundle in Orbit we actually compile? (In reply to comment #12) The primary issue is that Java 1.5 enums will not serialize properly because of the compiler settings of the orbit bundle, which should be set to the minimum required by its consumers. The 1.2 required execution environment is not necessary and should be removed. The CDC-1.1/Foundation-1.1 is the only one, which implies setting jre.compilation.profile = J2SE-1.4 in the build properties. The question is how should/do orbit bundles spec'd for lower version java environments handle the need of consumers that want to have it spec'd for a higher java version. This is the only json bundle version compiled in orbit.
>
> The question is how should/do orbit bundles spec'd for lower version java
> environments handle the need of consumers that want to have it spec'd for a
> higher java version.
>
Ok, well, sorry if I'm being dense here, but the BREE is a minimum level, so if someone wants to run with 1.5, what is it that prevents clients from using/serializing enums? I'm not doubting it, just trying to understand.
>
> The question is how should/do orbit bundles spec'd for lower version java
> environments handle the need of consumers that want to have it spec'd for a
> higher java version.
>
I didn't answer this very directly, but as far as I know, there is no way.
It is the author/producer of the bundle that spec's what the minimum version of Java is required. So in this case, even though we compile it, I'm assuming the original authors say its should be for JRE 1.2?
But you also mention
jre.compilation.profile = J2SE-1.4
Where does that come from, exactly?
Again, sorry if I'm being dense. Just trying to understand enough that maybe I can be helpful.
Also, you might ask questions on orbit-dev. There's plenty of people more experience with some of these things than I am.
I guess its pretty clear what your use case is ... JSON uses some reflection to access some other fields using reflection. I'll try to learn more by studying that, and the attached alternatives.
Created attachment 182252 [details]
simple test case
I tried to recreate the problem you are having, but can not. At least with my simple test case. Perhaps you could take a look at it, and change it so it demonstrates the problem?
It seems to run fine, and produces the output of
{"pages":234,"bookCategory":{},"title":"lal ala","db_Id":10}
which is I guess what's expected?
This runs fine in workbench, plus, it ran fine when I exported as an executable jar and ran from command line.
And I used json as is, checked out of cvs into workspace.
So ... I'm thinking ... maybe it has nothing to do with "compliance level".
Though that doesn't mean there is not still some other problem.
Perhaps its not being built correctly in Orbit's batch build?
Or, perhaps you can tweak my example code to demonstrate the error you are seeing, that is related to compliance level?
Created attachment 182268 [details]
slightly improved test case
This test case is slightly improved. I wrote it as an "Eclipse Application" to make it easier to test with the jar-as-built-by-Orbit.
And it works as before, giving this output:
{"pages":234,"bookCategory":{},"title":"lal ala","db_Id":10}
I used a recent platform
eclipse-platform-I20101102-0800-linux-gtk.tar.gz
and a recent json bundle
org.json_1.0.0.v201003050614.jar
Put the json bundle and the test bundle in dropins, and invoked with
./eclipse -debug -nosplash -console -application testjson.testbook -vm '/home/shared/webtools/apps/ibm-java-sdk-6.0-8.1-linux-i386/jre/bin/java'
So, since this all works, I'd be inclined to think of this as an "invalid" bug, instead of "won't fix" ... unless of course, it can be explained how my test case is not the right test case.
It is interesting to me that JSON, apparently, does not call the "toString" of the test Book object I wrote, or its getter or setters, apparently, but instead literally (I guess) accesses the fields of "Book". Perhaps that's a hint as to why the original use case was giving the error of
java.lang.IllegalAccessException: Class org.json.JSONObject can not access a
member of class org.eclipse.emf.texo.test.model.samples.library.BookCategory$2
with modifiers "public"
I am not able to explain why your test doesn't work in one case, but then does work if you change settings in the workspace. Perhaps if we use this "common" test case, we can help figure that out? Or figure out that there was something else going on?
(In reply to comment #16) > > But you also mention > jre.compilation.profile = J2SE-1.4 I set that value because of the result of a warning. After reading up on this property here: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_compilation_env.htm It seems that this build property has top priority over the compliance level of the build. The manifest header Bundle-RequiredExecutionEnvironment defines the minimum required execution environment, but is a secondary reference for building. So J2SE-1.4 is the correct compilation profile because it is the lowest version JRE that is compatible with CDC-1.1/Foundation-1.1 according to the chart in the above reference. I did test with your new bundle and also could not reproduce any problems. Dzmitry or Martin, can you use David's bundle or try to come up with an isolated test case that does break as you mentioned? Thanks. Created attachment 182493 [details]
JUnit Test bundle with David's Tests integrated
An EE in the bundle manifest of only Foundation-1.1 is almost certainly not what you want. This means you require a class library containing the Java ME-specific packages such as the javax.microedition packages which are not available in Java SE. I am running an application using org.json in a Java SE environment, and with your recent change the bundle no longer resolves. You likely should be specifying: Bundle-RequiredExecutionEnvironment: CDC-1.1/Foundation-1.1, J2SE-1.4 Which means, the intersection of Java SE 1.4 and Foundation 1.1 (the packages they have in common). Such an EE would allow the bundle to be run in both Java SE and Java ME environments. This is the setting used by most of the equinox bundles, for example. Note that Foundation 1.1 class library maps to Java 1.4 at the language level. Ie., your compiler compliance settings should be Java 1.4 if you are targetting Foundation 1.1 class libraries. I'm not sure what Austin was trying to accomplish (a test?) but as far as I can see, that change to EE was not released to a build ... is just what was in HEAD. Please correct me if I'm wrong. But, even with that, I've "reverted" (sort of) by checking in the EE John suggested. Sorry if you are/were testing something Austin, if so let us know (and you can use a sub-branch to do tests, if that was your intent). I say "sort of" above since previously the EE was "1.2". Is there a true requirement for that? If so, it still needs to be changed, back to 1.2, and in any case, needs to be released to a build once this is settled. (In reply to comment #22) > that change to EE was not released to a build ... is just what was in > HEAD. Oh, and what I meant was the "head" (or "top") of the v1_0_0 branch. Not sure what the right term is for that. (In reply to comment #22) John, Thanks for your input on this matter. That relationship between JRE Compliance and EEs had been a bit confusing. David, what you have checked in is correct in my opinion. I don't think there is a need for 1.2 in the EE, unless someone opens a bug on the matter. Since the code is so basic, the intent was just to provide an EE that was as compatible with as many consumers as possible. This bundle has always been a little bit different since the json.org people do not distribute binary versions of the code, which is why orbit actually builds this code. Do you want me to release this to the build or will you? I will leave the ticket open for a little while longer to allow the authors to come up with anything else. (In reply to comment #24) > Thanks for your input on this matter. That relationship between JRE Compliance > and EEs had been a bit confusing. Yes it is! > David, what you have checked in is correct in my opinion. I don't think there > is a need for 1.2 in the EE, unless someone opens a bug on the matter. Since > the code is so basic, the intent was just to provide an EE that was as > compatible with as many consumers as possible. J2SE 1.2 and Foundation 1.1 is a very strange combination - I'm not sure it makes any sense. As noted, Foundation 1.1 uses Java language version 1.4 and is a binary compatible subset of the class libraries in J2SE 1.4. The EE I suggested is quite broad - it means it will run on any Java ME profile Foundation 1.1 or greater, and any Java SE 1.4 or greater VM. This covers just about any JVM produced in the past 6+ years, and more importantly any JVM that can run a recent OSGi implementation such as Equinox. (In reply to comment #22) > I'm not sure what Austin was trying to accomplish (a test?) but as far as I can > see, that change to EE was not released to a build ... is just what was in > HEAD. > Please correct me if I'm wrong. Yep, I just have the 1.0 Orbit JSON branch in my workspace. Ok, I went ahead and tagged and released the version with 1.4 BREE instead of 1.2. Its admirable to go "as low" as you can, but seems to just be causing confusion here. Even though some changes were made due to discussion here, none of them really addressed the original reason for which the bug was open. So, with that, and the fact we have a simple test case that seems to work contrary to the original reason for which the bug was open. So, I'll close as 'worksforme'. Please do reopen if you can explain the flaw in the test case, etc., but so far I don't think the settings in this bundle is what caused the original issue. That said, I'm not very confident in how we build this bundle (since the only one in Orbit that is actually built) so I'd be happy to investigate further is something is (still) amiss. thanks (to everyone, originators, maintainers, and those that run with latest cvs branch code in their workspace :) Note: I did go ahead and check in the two attached tests into cvs. No plans to build or run them on a regular basis ... but would make it easier for others to see and provide patches to demonstrate the problem, if possible with these sample tests. I did change their names/packages to start with "org.eclipse.orbit...". The purest in me hates to use others namespaces, even if test or example code. org.eclipse.orbit.json.test org.eclipse.orbit.json.testapp |