Eclipse Data Tools Platform has a “Driver Definitions” entry, where you can indicate the JDBC drivers you want to use. When adding one, the wizard asks you to select a “driver template” from a provided list. In my eclipse Neon Java EE version, the list contains, among others, [Name=Other Driver; System Vendor=Derby; System Version=10.2], and [Name=Other Driver; System Vendor=Derby; System Version=10.1]. I can’t see a difference between these two templates, except that they end up with different indicated System Version as a result of the wizard (expectedly). However, in both cases (selecting the 10.2 line or the 10.1 line), when the wizard asks for a jar containing the driver, I use a jar containing the 10.10 version, so this indicated System Version is incorrect in both cases.
My questions are: how does eclipse use these version numbers? If it does not use them, why does eclipse bother displaying a list with different entries for different versions? Can I get problems if the version of the driver I use does not match the indicated one? Should I somehow tell eclipse the right version I use?
The system version is the supported (minimum) version of the target database. The definition of a higher version can contain new features, keywords, data types etc of that database version. In other words: improved/closer support for the database version you are targeting.
For example on of the differences between the Derby 10.1 definition and Derby 10.2 definition is the default length reported for blobs:
In 10.1:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="1024" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
In 10.2:
<predefinedDataTypeDefinitions xmi:id="BINARY_LARGE_OBJECT_1" lengthSupported="true"
defaultLength="2147483647" maximumLength="2147483647" primitiveType="BINARY_LARGE_OBJECT" jdbcEnumType="2004" javaClassName="java.sql.Blob">
Sometimes there might be no difference at all, but a separate (identical) definition might be provided just to avoid confusion for users to indicate that version is supported, and to make it easier to add corrections/improvements at a later time for that specific database version if necessary.
In short: use the version that is closest (but lower than or equal to) the version you are targetting; in this case: use the 10.2 definition.
Related
Since I am having a couple of angular projects within the same workspace along with Spring Projects, the Java Language Server that runs for providing Java support to VSCode takes an enormous time (~10 mins) to run through all the contents of the workspace which includes node_modules.
Is there a way/setting that I can use to tell it to skip certain folders/files so that I can speed up the initialization of the Java Language Server? Especially contents of node_modules?
As of v0.66.0 of the extension, there is the java.project.resourceFilters setting. As it defaults to ["node_modules",".git"], your problem should be solved by using a current version of the redhat.java extension.
If you'd like to exclude more folders, you can add them in your settings.json.
#1460 is the matching issue for this question.
--
But: this does not work for me atm. See #1655, my setting seems to be ignored, I'll try to resolve this with the devs and update this answer accordingly.
In Java, I often see JAR files named with the version number of the software (jsoup-1.11.2.jar), while others are not (freemarker.jar).
Is this just a best practice/convention, or is there some functional reason for it?
Simple answer: no, this is purely a convention.
Obviously, tooling that checks versions can do that easily when version numbers are hard-coded like this. But there is no generic (like jvm based) tool relying on it.
And beyond that - sometimes this scheme is even counter productive. In our self grown build setup we have to always remember to update the build scripts after replacing JAR files - because a new version changes the file name (because version part of the file name).
Having the version in the name of the file allows you to quickly determine which of the n files you have is the latest. Also if you have no way of determining what the version is from within the program it can be helpful.
I wanted to use a particular option -DentityExpansionLimit in java using a jdk and I was unsuccessful on an old version. I there anyway I can see which was the version this option was first implemented on? I was unable to find any answers and was hoping there is like a guide where an option was first implemented or even all the new features implemented for each version. Please let me know.
Seems like it was first introduced in Java 1.4.
Reference Links:
http://docs.oracle.com/javase/7/docs/technotes/guides/xml/jaxp/JAXP-Compatibility_160.html
http://www.oracle.com/technetwork/java/javase/relnotes-139182.html
As per the link:
New system property to limit entity expansion
The entityExpansionLimit system property lets existing applications constrain the total number of entity expansions without recompiling the code. The parser throws a fatal error once it has reached the entity expansion limit. (By default, the limit is set to 64000.)
To set the entity expansion limit using the system property, use an option like the following on the java command line: -DentityExpansionLimit=100000
I think your best option is to use google and check the release notes of each version.
Example: http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-429209.html
In your case, seems like your flag comes from JSDK v1.4.2
I have a Java EE web application developed in an old version of Eclipse (Ganymede if I remember correctly). I recently migrated to Kubuntu 12.04 LTS and migrated the application to Eclipse Kepler (which I downloaded and installed from the Eclipse website). It is using Java Compliance Level 1.6 and the target container is Tomcat 6.
My problem is that I now receive the error:
org.postgresql.util.PSQLException: ERROR: operator does not exist: integer = character varying
when the application encounters a page with a certain Postgres query in it. I'm using the JSTL sql:query and sql:param tags to implement a prepared statement within the jsp page. I know this is considered bad practice, but I'm not the original author and this technique is used throughout the application.
The error occurs because of trying to assign a string to an integer in the sql:param tag. In the previous setup any casting happened transparently and there was no error. With the new setup I receive the error.
I read that more strict type casting was introduced with Postgres 8.3 which would cause this error, but I am using the Postgres 8.2 JDBC 4 jar file within my application so it should work. I am stumped. Perhaps someone has an idea?
I came across a workaround, to multiply the string by 1 before making the comparison:
http://dev-answers.blogspot.co.uk/2010/08/type-coercion-in-jstl-for-sqlparam.html
But this is a bit of a kludge and I would have many pages to modify. But it is academic because I should not be experiencing the problem anyway.
Thanks for reading. Any help greatly appreciated.
You might be using the PostgreSQL 8.2 JDBC driver, but it looks like you're using a newer PostgreSQL server version. Try:
SELECT version()
Betcha it's 8.3 or newer.
These queries aren't really right and should preferably just be fixed. If you must you can alter the system catalogs to allow the cast implicitly, but this should be a temporary workaround only, until you can fix the queries the application is sending. The workaround proposed in that blog post is horrible, but so is JSTL if it doesn't offer type casts in a heavily typed language. Personally I'd be more inclined to force an explicit coercion in the query, eg in the blog's example:
<sql:query var="examples" dataSource="${exampleDataSource}">
select ExampleName as "name"
from ExampleTable
where ExampleId = ?::integer
order by ExampleName ASC
<sql:param value="${param['ID']}"/>
</sql:query>
? :: integer is a type cast in the PostgreSQL shorthand syntax. You can write the SQL standard CAST(? AS integer) if you prefer.
See:
The PostgreSQL 8.3 release notes
Peter's blog post
The lesson here: Always read the release notes of major version upgrades before you upgrade.
Heading
I'm working on a Java Swing-based application+ Hibernate+Mysql+Spring.
When I test CRUD operations, I don't have problems with read, but in insert statements system shows the message:
Unknown system variable `tx_read_only`
I have the last version of MySQl
Hibernate 4
Java annotations
Can you tell me which is the problem to solve now?
Just throwing rocks to the darkness, but one possibility could be:
Variable tx_read_only was introduced in MySQL 5.6.5.
Probably MySQL version is older than that, but Connector/J tries to use new variable anyway.
According release notes, support for this variable came in Connector/J 5.1.23.
==> maybe version older than 5.1.23 will work, or this is the bug that is fixed in version newer than that.
In my case I was connecting to mariadb with default innodb url format.
So it was selecting the wrong driver
Incorrect: jdbc:mysql://
Correct: jdbc:mariadb://
upgrade mysql-connector-java>=5.1.46
see: https://dev.mysql.com/doc/relnotes/connector-j/5.1/en/news-5-1-46.html