Community
Participate
Working Groups
We have observed that the JSF build appears to to succeed, yet the latest EMF driver should be causing compile errors. This bug is opened to track.
How do you have your compiler compliance level set? It's my understanding that if you have it set to Java 5, you may get some errors, but if you set it to 1.4 (with source and byte level set to 1.4) then you will not get the compiler failures.
I should have been more explicit, it helps with some issues, such as class casts. If it's more than class cast failures then I'd have to know more detail.
Ah, damn it! Burned by compliance level again. It's so stupidly easy to forget...
(In reply to comment #3) > > It's so stupidly easy to > forget... > Well, actually, you can (and probably should) set "project override settings" so that no matter what someone's workbench settings are, they will be correct for that project ... in their IDE.
The harder question is _should_ you set it to 5.0 or 1.4 compliance level? From what I know, setting it to 1.4 is good, and requires less change. From you and your clients. (Even though we'll all be running on Java 5, we want to avoid forcing anyone to change source, if at all possible). I _think_ setting it to 5.0 is the (only?) way to "pass on" the joy of Java 5 to your clients, via your API, if this effects any of your API ... but I am not exactly sure. I'm CCing Ed to see if there's any general "EMF advice" on this topic. Ed, one of the main cases in point is code that looks like that pasted below. I _think_ if Cameron, et. al., wanted to be purely Java 5 conformant, they would have to re-generate their models ... is that right? And, if so, what are exactly the advantages of doing to? Does it have an impact on clients that might call their API? Or, do their clients still, then, just have the "choice" of compiling to Java 5 or Java 1.4 compliant source? The following code generates a compile error if we ask to comply with Java 5, but if set to Java 1.4. /** * <!-- begin-user-doc --> * <!-- end-user-doc --> * @generated */ public FeatureMap getGroup() { return (FeatureMap)((FeatureMap)getMixed()).list(FacesConfigPackage.eINSTANCE.getAttributeExtensionType_Group()); }
> Well, actually, you can (and probably should) set "project override settings" > so that no matter what someone's workbench settings are, they will be correct > for that project ... in their IDE. That's a good idea.
David, Yes, if Cameron wants to be fully supporting Java 5.0 in his APIs he'd need to regenerate (after setting the GenModel's compliance level to 5.0) and recompile. If he does that, his clients can ignore the APIs changes or not the same way as he himself has this choice. The advantage of moving is the additional static type saftey his clients will enjoy. I'm not sure there really is a disadvantage since clients can choose to ignore this if he provides it but they can't choose to enjoy it if he chooses not to provide it.
Closing as part of mass query to clean up old resolved bugs in untargetted milestones.
