Community
Participate
Working Groups
"org.eclipse.jface.databinding" is included in the RCP drops (as of tonight's nightly builds). As such, it must only use foundation library code. To set up a foundation environment, do the following: 1.) Check out "org.eclipse.osgi" 2.) Open the properties on "org.eclipse.jface.databinding" 3.) Go to the Java Build Path > Libraries 4.) Remove JRE System Library 5.) Add JAR: "org.eclipse.osgi/osgi/ee.foundation.jar" optional: add "org.eclipse.osgi/osgi/XMLParserAPIs.jar" as well
... and don't commit the change to .classpath when you do this
Fixed one part of this. The JavaBeans classes are not part of Foundation, we need to discuss what we can do.
I talked to Nick about this, and he said that we might get away with a couple "impurities" as long as it is a small contained piece of the data binding framework. Right now, the JavaBeans model support is contained in one package.
While I think this is true, I think that it would be best to separate the non-Foundation pieces into their own plug-in.
Jeff, do you have any recommendations here? We have a few cases where our choice of dependencies requires splitting out some pretty fine-grained plug-ins if we're going to be strict about it. Another case is the action set for Update currently in org.eclipse.ide, which should really belong in an org.eclipse.update.ui.ide plug-in.
Boris, I think the only JavaBeans stuff we use is the Introspector and BeanInfo stuff, right? If so, it's not hard to re-create the important parts of that and just eliminate the dependency. That's what I did for Sweet (which is in CVS). I know that Sweet uses dynamic proxies, which is also non-foundation, but maybe it could be used as a reference for implementing our own support.
The problem is PropertyChangeListener. We cannot register a listener with a bean object without implementing this class, which is not part of foundation if I'm not mistaken.
Hmmm, lots of little plugins would be unfortunate. It would likely be better to go down the path of having optional pieces within the plugin and clearly documenting them as needing a differnet JRE. To that end we should come up with a conventional form and place for such notices.
> To that end we should come up > with a conventional form and place for such notices. Ideally, automatic checking should be possible for cases like this too, if not as part of PDE, then as part of the build process.
Not sure what we would check. It either compiles or it does not. If you want it to compile the you have to setup the build.properties correctly. Needing to do this is a sure sign that something in the plugin needs more detailed JavaDoc indicating what works only if a certain JRE is available.
In the meantime, we have grown more dependencies on non-foundation classes. - PropertyChangeListener and other JavaBean classes for bean model support - DecimalFormat, DateFormat from java.text for validators Treating these as "impurities" in separate packages has the drawback that the tooling does not enforce that you can still run a sizeable part of the plug-in using just the foundation class library. We would have to check this manually every now and then. Because of that, I'm leaning towards either spliting into two plug-ins, or giving up on the goal of supporting foundation and requiring the full 1.3 or 1.4 class libraries.
+1 for splitting (if anyone cares <g>)
-1 for giving up +1 for something that means you don't have to give up
(In reply to comment #13) > -1 for giving up > +1 for something that means you don't have to give up Let me see if I can rephrase the problem and maybe that will help us work it: The whole data binding framework depends on one foundational interface (pun not intended): /** JavaDoc removed */ public interface IUpdatable { public void addChangeListener(IChangeListener changeListener); public void removeChangeListener(IChangeListener changeListener); public void dispose(); } Right now the change notification contract above can be satisfied one of two ways: 1) By using EMF and building on its change notification mechanism. 2) By using java.beans.* with its PropertyChangeListener interface. Our problem, then, is that neither (1) or (2) is foundation and that a lot of folks would prefer to work with POJOs than with EMF. So it seems that if we must be able to run on Foundation, that our only real choice is to invent our own change listener interface to use in place of java.beans.PropertyChangeListener, if java.beans.PropertyChangeListener isn't present. This would imply creating a new eclipse.beans.PropertyChangeListener (or something) and creating a new (EclipseBeanUpdatable, EclipseBeanUpdatableValue, EclipseBeanUpdatableCollection, ...) It's ugly, but it would work. I don't think that this should replace our java.beans implementation because I don't think we can credibly claim to be a generic data binding framework without supporting java.beans. Thoughts, comments, other ideas?
(In reply to comment #14) > So it seems that if we must be able to run on Foundation, that our only real > choice is to invent our own change listener interface to use in place of > java.beans.PropertyChangeListener, if java.beans.PropertyChangeListener isn't > present. Maybe the answer is staring me in the face. Here's another idea: Maybe this new change listener interface is just IChangeListener above... :-) (see comment 14) The semantics for using them are identical to using the JavaBeans addPropertyChangeListener(pcl), removePropertyChangeListener(pcl), etc. We still would need a new EclipseUpdatableValue, EclipseUpdatableCollection, and so on that can recognize addChangeListener(IChangeListener), removeChangeListner(IChangeListener), and so on. And as I mentioned in bug #118570, we need to separate classes (like this IChangeListener) that folks will put in their models into a separate plug-in since these models might run inside a web server or other application server, and dragging in data binding, which drags in JFace which drags in SWT will be unacceptable in that environment. Thoughts?
Changing priority to P2.
We are almost there. The remaining non-foundation dependency is on String.matches() and the package java.util.regex. This is currently used in the validator classes. To get rid of these dependencies, I see two alternatives: 1. Remove RegexStringValidator, and implement the *2*PrimitiveValidator classes in a way that does not use regular expressions. I.e., translate the existing regular expressions into code that uses startsWith(), indexOf(), substring() and the like. 2. Move the default validators (and converters?) into org.eclipse.core.databinding.beans, which can use 1.4 level API. This would be easier to do, but it also means that we would have to add a convenience method to the beans plug-in to create a vanilla data binding context and use that in most cases instead of just calling a constructor on DataBindingContext. Thoughts? Comments?
BTW, if you want to set up Eclipse with a foundation-1.0 execution environment, here are the steps that worked for me: http://wiki.eclipse.org/index.php/J9
There is an in between option that says you use regex if available. The frustrating thing about the Bundle-RequiredExecutionEnvironment setting is that it is multi-purpose. It covers things like language level features (generics, assertions, ...) and byte code type codes to JRE classes. The latter is a problem because often the same classes are available from other sources. XML parsing is a perfect example. As is JMX support. We have bundles that supply these API and implementations independent of the underlying JRE. (Note that with the new bootdelegation support you will actually be able to use these other implementations even in the face of them existing in the JRE). So, what I am getting at here is if you Import-Package the regex things you need then any old bundle that has them can supply them to you. Then the quesiton for you becomes, can you run without regex. If you can, make the Import optional and do your pattern matching conditionally. For example, check to see if regex is there, if so, use it, if not, do something else (graceful degradation) This is not always possible but it is a useful approach if you can swing it.
(In reply to comment #17) > We are almost there. The remaining non-foundation dependency is on > String.matches() and the package java.util.regex. This is currently used in > the validator classes. > > To get rid of these dependencies, I see two alternatives: > > 1. Remove RegexStringValidator, and implement the *2*PrimitiveValidator classes > in a way that does not use regular expressions. I.e., translate the existing > regular expressions into code that uses startsWith(), indexOf(), substring() > and the like. Either this or Jeff's suggestion are my choices. I also bet a brain-dead simple regex engine without bells and whistles would be pretty easy to code too, if we needed. It wouldn't compile to a finite state machine, but for our work, we don't normally need that performance. This could be the default if Java's regexes aren't available. Another thought--Is Apache ORO approved/used anywhere in Platform? If we do #1 here, I suggest that we move the regex validator to a non-foundation package--maybe the JavaBeans one. It's too useful to give up entirely.
I believe ORO or something compatible is used in other projects. I think I saw someone talking about it in Orbit. In any event, if you can code a path that makes regex optional then it really doesn't matter. People who want ot use it can add ORO/whatever
If possible, I would like to keep core.databinding clean - this makes it easy to check that we are only using foundation/1.0 classes. It also avoids the complexity of having optional dependencies, and parts of the API that depends on those optional dependencies. About moving RegexStringValidator to core.databinding.beans - I initially thought this was a good idea, until I tried to move it and had to pick a package name in the new plug-in for it. Packages in core.databinding.beans should have that prefix, and the regex stuff clearly has nothing to do with beans. I then looked at the class again and realized that it is just a convenience implementation. It does not have any interesting code on its own, so I would suggest for now that we remove it. Clients can still create validators based on regexps by just delegating to the 1.4 API available to them. If we could agree on taking approach #1 and removing RegexStringValidator, all we need before we can close this bugzilla is someone who implements the *2*PrimitiveValidator classes without using regexps. Any volunteers? ;)
This was fixed in 3.3.
