On 22.04.10 18:27, Ян Программист wrote:
Runtime checks of transaction related locks require good thread based
performance. Currently there where problems with reflection API,
especially null arguments. If community will reject in helping me with
Java 6 support of VTI sources - than I will have to reject
multi-transactional support for that XML-to-SQL translation stuff.
Especially in focus of ORM/JDO trageting to Java 6 (all Java ORMs
currently require Java 6 because of annotations). John
P.S. You haven't responded about an idea of community voting against
XML parser to support in SQL/XML for Derby. I asked you about that at
least 2 times (if I am not wrong), Respond to derby-dev
John,
As a member of the community, I'm not required to answer your posts.
I don't have to explain myself either, but here's why I haven't
responded to your posts (both privately mailed and on the list):
- I don't have much hands-on experience with XML (neither in general,
nor in relation with SQL)
- I have other responsibilities, both professional and personal,
which have higher priorities
- to be honest, I sometimes have problems understanding your posts. I
don't understand what kind of feedback you are expecting.
English isn't my native language, probably not yours either.
Different languages can be an issue at times, but we don't have many
other appealing options than being patient and try our best to write
clear and polite posts.
When I ask questions, I mostly address them to the community as a whole
- not to a specific person. There are exceptions of course, for instance
when I have been working closely with another member of the community on
a specific issue.
That said, even if I write "John, why is this piece of code behaving
like this?", any community member is free to pitch in and reply to my
post. Further, the fact that a person answers one question doesn't mean
that this person is obliged to answer follow-up questions.
Finally, it may be hard for people to understand the problems you are
referring to because you haven't posted any code yet. Unless people have
a special interest in the topic, one can't expect everyone to spend a
lot of time investigating broad topics like XML support in databases and
the implications for ORM frameworks using annotations.
Assuming the ORM interacts with Derby through JDBC, I suppose the ORM
can be compiled independently of Derby using Java 6 features.
Where do you need to use annotations in the Derby source code?
Nobody has rejected to help you. Maybe people are having difficulties
understanding how they can help you?
--
Kristian
2010/4/22 Kristian Waagan <kristian.waa...@sun.com
<mailto:kristian.waa...@sun.com>>
On 22.04.10 17:25, Ян Программист wrote:
init:
deps-clean:
Deleting directory /home/webautomator/NetBeansProjects/derby/build
clean:
init:
deps-jar:
Created dir:
/home/webautomator/NetBeansProjects/derby/build/classes
Created dir: /home/webautomator/NetBeansProjects/derby/build/empty
Compiling 1714 source files to
/home/webautomator/NetBeansProjects/derby/build/classes
/media/4c618535-dce4-4aa5-b621-475b44dd7adf/trunk/java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java:60:
warning: [deprecation]
org.apache.xalan.serialize.DOMSerializer in
org.apache.xalan.serialize has been deprecated
import org.apache.xalan.serialize.DOMSerializer;
/media/4c618535-dce4-4aa5-b621-475b44dd7adf/trunk/java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java:61:
warning: [deprecation] org.apache.xalan.serialize.Serializer
in org.apache.xalan.serialize has been deprecated
import org.apache.xalan.serialize.Serializer;
/media/4c618535-dce4-4aa5-b621-475b44dd7adf/trunk/java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java:62:
warning: [deprecation]
org.apache.xalan.serialize.SerializerFactory in
org.apache.xalan.serialize has been deprecated
import org.apache.xalan.serialize.SerializerFactory;
/media/4c618535-dce4-4aa5-b621-475b44dd7adf/trunk/java/engine/org/apache/derby/iapi/types/SqlXmlUtil.java:118:
warning: [deprecation] org.apache.xalan.serialize.Serializer
in org.apache.xalan.serialize has been deprecated
private Serializer serializer;
/media/4c618535-dce4-4aa5-b621-475b44dd7adf/trunk/java/engine/org/apache/derby/iapi/sql/dictionary/TableDescriptor.java:152:
warning: [unchecked] unchecked call to put(K,V) as a member of
the raw type java.util.WeakHashMap
map.put(this, newReferencedColumnMap);
^
/media/4c618535-dce4-4aa5-b621-475b44dd7adf/trunk/java/engine/org/apache/derby/iapi/sql/dictionary/TableDescriptor.java:667:
warning: [unchecked] unchecked call to add(E) as a member of
the raw type java.util.ArrayList
relevantTriggers.add(tgr);
[ snip ]
Hi John,
Just want to point out that there's a difference between Java 6
compatibility and actually using the new Java 6 features / interfaces.
Derby can be run with Java 1.4, 5.0 and 6 (and 7), but most of the
source code is written based on the 1.4 specification. This is
indeed annoying at times, when you want to use nifty new features
and methods. However, this will probably continue until the
community decides to drop support for small platforms, or the
small platform Java specification moves to the Java 5.0+ level.
When it comes to Derby and IDEs, like NetBeans, you may get better
results if you define the code to be at level 1.4 rather than 5/6.
You will still get some errors, but fewer.
Since the Derby build process is rather complex, I tell NetBeans
to use the ant targets in build.xml for building the source code.
Regards,
--
Kristian
