We Keep Coding

Difference between InputStreamReader in java 1.6 and java 1.7 [duplicate]

We are migrating our application from Java 1.6 to Java 1.7. We recompiled the code using Java 1.7 and received an error while compiling which was due to a character (an Ó).
Was there a change in Java 1.7 related to characters? Our application does a lot of processing of incoming files to then load them into a database and I want to ensure that when we upgrade to Java 1.7 that the reading of a file from java and the writing to the database of that content wont result in some odd character conversions.
Do I need to be concerned at all when upgrading to 1.7? If so, how to I get the same encoding that we had in Java 1.6?

The error occurs because you've told the Java compiler that your source is UTF-8 encoded, but it still contains some ISO-8859-1 extended characters. I recently had to fix similar errors in a codebase that was migrated from 1.5 to 1.6. I believe that Java 7 is much stricter about UTF-8 encoding than previous versions and will issue errors where previously the incorrect encodings were silently accepted.
You will need to make sure that your source code is "Unicode-clean", that is, you must replace any extended ISO-8859-1 characters with their Unicode equivalents.

I ran into this problem on Windows and discovered that the default encoding for 1.7 was CP-1252. I was able to get clean compiles by setting to following environment variable...
JAVA_TOOL_OPTIONS = -Dfile.encoding=UTF8

Unable to run JOOQ GenerationTool with Java 11 (NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema)

I attempted to run the code gen with this command line as described in the documentation here:
java -classpath "jooq-3.12.3.jar;jooq-meta-3.12.3.jar;jooq-codegen-3.12.3.jar;mysql-connector-java-5.1.18-bin.jar;." org.jooq.codegen.GenerationTool library.xml
I get the following error:
Jan 10, 2020 5:10:45 PM org.jooq.tools.JooqLogger info
INFO: Initialising properties : library.xml
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
at org.jooq.util.jaxb.tools.MiniJAXB.getNamespace(MiniJAXB.java:389)
...
I'm using Java 11:
openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)
What am I missing?
PS. I'm very new to the world of Java...

The problem is connected with removal of JAXB api as it was considered a part of JAVA EE API, thus removed form JDK since Java 9 (see this question for details).
You can solve your problem by adding jaxb-api jar to your classpath :
java -classpath "jooq-3.12.3.jar;jooq-meta-3.12.3.jar;jooq-codegen-3.12.3.jar;reactive-streams-1.0.2.jar;mysql-connector-java-5.0.7.jar;jaxb-api-2.3.1.jar" org.jooq.codegen.GenerationTool library.xml
Notice that I also had to add reactive-streams-1.0.2 jar to the classpath (as the tutorial mentions).
And change the MySQL driver jar to your jar in the command I pasted. So the final command in your case will be :
java -classpath "jooq-3.12.3.jar;jooq-meta-3.12.3.jar;jooq-codegen-3.12.3.jar;reactive-streams-1.0.2.jar;mysql-connector-java-5.1.18-bin.jar;jaxb-api-2.3.1.jar" org.jooq.codegen.GenerationTool library.xml

The JAXB API is an unfortunate external dependency of jOOQ, which we've been trying to remove step by step in recent versions. We've already removed the JAXB implementation dependency, but the API, we still depend on in various parts of jOOQ.
It should be possible to use jOOQ and jOOQ's code generator without explicitly putting the JAXB API on the classpath also in JDK 11+. I've created an issue to resolve this particular problem: https://github.com/jOOQ/jOOQ/issues/9723
The MiniJAXB class is already a workaround to avoid depending on the JAXB implementation. jOOQ should also avoid depending on the JAXB API, in the future.
For the time being, michalk's solution is the only viable one if you do not want to use Maven or Gradle to resolve your transitive dependencies for you.

Liberty server with java 1.8

Getting below error while deploying application in liberty server.
It seems drools compatibility issues with java 1.8.I cannot change my drools / mvel jar version since it requires significant change in drools. In one of the forum , i have read to use updated ecj version jar So I have updated ecj jar to 4.5.1 version but even though getting the error .This solution works in tomcat and WAS Server without any issues with java 1.8 migration
Caused by: java.lang.VerifyError: (class: ASMAccessorImpl_7258891721511957152780, method: getKnownEgressType signature: ()Ljava/lang/Class;) Illegal type in constant pool.
Can anyone please let us know what need to do for solving the above error

Normally I've seen this problem occur when using .class files compiled with one JDK and running with another (e.g. compiled w/ IBM JDK 7 and running with Oracle JDK 8).
To work around the VerifyError you can add -noverify to your JVM_ARGS (via jvm.options).
For more detailed analysis it would be helpful to know:
the complete stack trace of the error
what JDK you are running with
the version of WAS Liberty you are using

Unsure if I am using the correct version of Java for Eclipse

I am having a bit of trouble determining if I am running the correct version of Eclipse and/or Java. I am attempting to make changes to a JAXB program for work. I can't run the program and an error is generated that states
java.lang.UnsupportedClassVersionError: RunISOPaymentFileSimulator : Unsupported major.minor version 51.0
I know from doing my research using the search function this means that I need version J2SE 7.
After searching for my current version I find that I have Java 6 Standard Edition build 1.6.0.
My question is this: Is Java 6 the same thing as J2SE 6? Do I need to just update my Java version to 7 or do I need to also find the special J2SE 7?
Thanks very much!

Neither Java not J2SE is specific enough. What you need is the Java 7 JRE (Java Runtime Environment.) You probably already have it but your JAVA_HOME is set to 6. Changing your JAVA_HOME can cause issues for some applications that are written poorly so be prepared to have to switch it back.
http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1880261.html

Netbeans: Setting up java cross-compilation

I intend to write private-use command line tools in java for use both on my private system (jdk 7) and on my universities number-crunching servers (jre 1.4). An attempt at installing OpenJdk from sources failed, because it is missing several dependencies, that simply wouldn't make sense on a computation server -- e.g. CUPS. The work required for installing such dependencies and THEIR dependencies would probably defeat the whole point of automating tasks, i.e. making life easier.
Being used to the conveniences of generics, I don't want to write 1.4 SOURCE code though. I found that, when compiling from the command line, options like
javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip \
-extdirs "" OldCode.java
are available (see [1]), which should allow compiling jdk5 or even jdk7 specific syntax to jdk1.4 compatible bytecode, as long as I stay clear of newer library features (which -bootclasspath is for).
This brings up two problems:
While I can set the compliance level for each project to a given java version easily in Netbeans 7.3, it forces me to use 1.4 syntax as well (probably by adding -source 1.4 to the command above).
I couldn't find an old jdk (specifically classes.zip) anywhere except for oracle.com, where registration is required for downloading those with the registration mask alone making quite clear that those are not meant for private use.
All related answers I found so far give no hint how to do this kind of bytecode/source-separated cross-compilation in netbeans and none address the issue of finding old JDKs.
Eclipse is not really an option, as there I couldn't figure out how to get automatic generation of JARs like in netbeans.
Any ideas?
Platform details:
Local (from Netbeans "Help → About"):
Product Version: NetBeans IDE 7.3 (Build 201302132200)
Java: 1.7.0_11; Java HotSpot(TM) 64-Bit Server VM 23.6-b04
Runtime: Java(TM) SE Runtime Environment 1.7.0_11-b21
System: Windows 7 version 6.1 running on amd64; Cp1252; de_DE (nb)
Remote:
java version "1.4.2_11"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_11-b06)
Java HotSpot(TM) 64-Bit Server VM (build 1.4.2_11-b06, mixed mode)
Update: Just to be sure -- it IS possible to compile source with new syntax to Java 1.4. E.g. I wrote this file:
class Target<T>{
public T field;
public static void main(String[] args){
System.out.println("Hello World!");
Target<String> target = new Target<>();
target.field = "More Worlds.";
System.out.println(target.field);
}
}
Then I compiled it with JDK 7 doing
javac -target jsr14 Target.java
and uploaded it to the computation server, where only JRE 1.4 (and no JDK at all) is present. It gave the expected output
Hello World!
More Worlds.
Apparently the "jsr" targets are an undocumented feature though, see e.g. [2]. Also that link mentions, that it is a bit of a hack, as only for-each loops for the Collections library will be handled:
for-each loop: When iterating over an array, the compiler generates an induction variable and the standard array iteration idiom. When iterating over a Collection, the compiler generates the standard iterator-based idiom. When iterating over a non-Collection Iterable, the compiler produces an error.
I guess that means, that I will have no choice but to attempt getting a newer JRE onto the server, if I want to use any reasonably modern features...
[1] How do i compile a .java with support for older versions of java?
[2] http://twit88.com/blog/2008/08/26/java-understanding-jsr14/

JDKs aren't forward-compatible. That is, you cannot compile new features for old JDK versions. (or JRE for that matter).
Language constructs, such as generics, are if I'm not totally mistaken, part of the bytecode or interpreter in Java.
AFAIK you have only two options. 1) install new JDK or 2) write 1.4 source code.