Normalizer.DECOMP is not anymore in java 7 - upgrade

I have this in my code:
String name
StringnormString=Normalizer.normalize(name, Normalizer.DECOMP, 0);
this code is build in java 1.5 and I try to upgrade to java 1.7 but I cant find what the constant Normalizer.DECOMP means in java 1.7

Try this Normalizer.normalize(name, java.text.Normalizer.Form.NFD);
Normalizer api changed slightly in java 6,so its usage is a bit different now.

Related

NoSuchFieldException on executing ClassLoader.class.getDeclaredField("libraries") in Java 17

java.lang.NoSuchFieldException: libraries
at java.base/java.lang.Class.getDeclaredField(Class.java:2610)
Wondering how Eclipse-debug is able to access and display the values:
Eclipse-debug
Working fine though, in Java 11:
Field nativeLibsField = ClassLoader.class.getDeclaredField("nativeLibraries");
nativeLibsField.setAccessible(true);
With Java 12 a filter was introduced for access to fields via reflection of the following classes:
java.lang.ClassLoader
java.lang.reflect.AccessibleObject
java.lang.reflect.Constructor
java.lang.reflect.Field
java.lang.reflect.Method
You can see the issue in the issue tracker. This is the commit, that introduced this change in OpenJDK.
I don't actually know this, but I guess that Eclipse is using the Java Debugging Interface instead of reflection to access this information.

Error in running a plugin in imageJ

I am using imageJ (Fiji) version: 2.0.0-rc-43/1.50e
I installed a IHC_Profiler (https://sourceforge.net/projects/ihcprofiler/)
And when I run it, it shows a console with this:
Compiling 1 file in
/var/folders/k2/kdrnsbws5gz8vrt83yjmlbdm0000gn/T/java744586229414007803
/var/folders/k2/kdrnsbws5gz8vrt83yjmlbdm0000gn/T/java744586229414007803/src/main/java/IHC_Profiler.java:10: cannot access java.lang.Object
bad class file:
ZipFileIndexFileObject[/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/lib/ct.sym(META-INF/sym/rt.jar/java/lang/Object.class)]
class file has wrong version 52.0, should be 50.0
Please remove or make sure it appears in the correct subdirectory of the classpath.
public class IHC_Profiler implements PlugIn {
When I use imageJ 1.48 version, it is okay. I wonder if this problem can be solved?
You are running Fiji with Java 8, but without the Java-8 update site enabled.
The easiest solution is to download a fresh Fiji, which comes with the Java-8 update site enabled out of the box.
See this guide for details:
http://imagej.net/2016-05-10_-_ImageJ_HOWTO_-_Java_8,_Java_6,_Java_3D

Using j2pkcs11.dll with java 8 (64-bit) on windows 7 (64-bit)

I trying to use the j2pkcs11.dll (packaged with jdk1.8.0 - 64bit) to access certificates stored on a smartcard but not unable to make it work.
--- sample code to add the SunPKCS11 provider dynamically ---
String pkcs11ConfigSettings = "name = " + "TestSmartCard" + "\n" + "library = " + "C:/jdk1.8.0_11/jre/bin/j2pkcs11.dll";
byte[] pkcs11ConfigBytes = pkcs11ConfigSettings.getBytes();
ByteArrayInputStream confStream = new ByteArrayInputStream(pkcs11ConfigBytes);
Provider p = new sun.security.pkcs11.SunPKCS11(confStream);
---- the exception I get ---
java.security.ProviderException: Initialization failed
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:376)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:103)
at scpoc.SmartCard.main(SmartCard.java:28)
Caused by: java.io.IOException: The specified procedure could not be found.
at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method)
at sun.security.pkcs11.wrapper.PKCS11.<init>(PKCS11.java:138)
at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151)
at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:313)
JEP 131 claims to have PKCS11 support in Java 8 (http://openjdk.java.net/jeps/131) but I have not been able to get it to work on windows 7 using the java8 64-bit. Note: I also tried the java 8 32-bit on windows 7 - but no luck either.
Has anyone had any success using the SunPKCS11 provider with java 8 (Windows 7)?
SunPKCS11 provider is present only in 32-bit Windows version of JRE up until JRE7. Since JRE8 it is present also in 64-bit Windows version of JRE. This is the information you see in JEP131.
If you need to use PKCS#11 API in 64-bit Windows version of JRE older than JRE8 then you will have to use one of alternative 3rd party implementations - such as IAIK-JCE.
I have also noticed in your code sample that you are trying to directly use "j2pkcs11.dll" as a PKCS#11 library which is wrong because it is just a JNI wrapper sitting between JRE and the library implementing PKCS#11 interface. Instead of loading "j2pkcs11.dll" you need to load PKCS#11 library provided by your smartcard or HSM vendor.

Static type checking error for groovy collection.addAll

This message is also posted on grails mailing list.
In addition to my earlier question I downloaded the grails source from github.
Building via documented gradlew install works (almost) perfect. Than I imported the whole project into Eclipse. And with a bit fighting groovy plugins and "project - workspace-groovy-compiler-issues" I only have a few issues left, all boiling down to java Collection modification in groovy classes. For instance in PluginBuildSettings.groovy:
List<Resource> artefactResourcesList = []
...
artefactResources.addAll compileScopePluginInfo.artefactResources
which gives an error:
Groovy:[Static type checking] - Cannot call java.util.List#addAll(java.util.Collection ) with arguments [java.util.Set ]
I really don't see what the issue may be.
I tried changing the artefactResources declaration in PluginScopeInfo from:
Set<Resource> artefactResources = []
to:
Set<Object> artefactResources = []
which takes away error above, but introduces some other problems let alone the unittests. I'm not hindered with extensive groovy knowledge but it looks all perfect valid to me.
I'm using ggts:
Groovy/Grails Tool Suite
Version: 3.1.0.RELEASE
Build Id: 201210061306
groovy-compiler: 2.0.4.xx -20120921
On mac os x 8.2
java 6.0._37
groovy compiler: 2.0 (workspace and project).
With my favorite search engine I found a reference to grails bug 5516, which is solved but it looks resurected
Type checker fails verification of generic types with addAll
Fixed in 2.0 rc 3,

Restlet proxy generation fails with latest GWT 2.5.0-RC1

Upgraded to GWT 2.5.0-RC1 and the proxy generation for Restlet breaks - I have the latest release 2.1-RC6 in my project. This is the stack trace :
java.lang.NoSuchMethodException: com.google.gwt.user.rebind.rpc.SerializableTypeOracleBuilder.<init>(com.google.gwt.core.ext.TreeLogger, com.google.gwt.core.ext.PropertyOracle, com.google.gwt.core.ext.typeinfo.TypeOracle)
at java.lang.Class.getConstructor0(Class.java:2706)
at java.lang.Class.getDeclaredConstructor(Class.java:1985)
at org.restlet.rebind.ClientProxyGenerator.getSerializableTypeOracleBuilder2_2(ClientProxyGenerator.java:767)
at org.restlet.rebind.ClientProxyGenerator.generateSerializers(ClientProxyGenerator.java:569)
at org.restlet.rebind.ClientProxyGenerator.generateProxy(ClientProxyGenerator.java:500)
at org.restlet.rebind.ClientProxyGenerator.generate(ClientProxyGenerator.java:242)
The actual exception gets thrown here :
private SerializableTypeOracleBuilder getSerializableTypeOracleBuilder2_2()
throws Exception {
SerializableTypeOracleBuilder result = null;
Constructor<SerializableTypeOracleBuilder> c = null;
c = SerializableTypeOracleBuilder.class.getDeclaredConstructor(
TreeLogger.class, PropertyOracle.class, TypeOracle.class);
result = c.newInstance(getLogger(), getContext().getPropertyOracle(),
getTypeOracle());
return result;
}
This following call seems problematic, though I do not see why :
c = SerializableTypeOracleBuilder.class.getDeclaredConstructor(
TreeLogger.class, PropertyOracle.class, TypeOracle.class);
Somebody got Restlet GWT working with the latest GWT 2.5.0-rc1 ??
UPDATE: issue opened #647
I just checked the POMs for the following GWT versions of Restlet:
http://maven.restlet.org/org/restlet/gwt/org.restlet/2.2-SNAPSHOT/
http://maven.restlet.org/org/restlet/gwt/org.restlet/2.1.1/
and they all have dependencies on version 2.2 of GWT.
That's the problem when using internal classes: SerializableTypeOracleBuilder's constructor no longer takes a TypeOracle argument, but a GeneratorContext.
http://code.google.com/p/google-web-toolkit/source/browse/releases/2.5/user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java#782
That was already the case in GWT 2.4 though (with the experimental GeneratorContextExt instead): http://code.google.com/p/google-web-toolkit/source/browse/releases/2.4/user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java#747
and even GWT 2.3: http://code.google.com/p/google-web-toolkit/source/browse/releases/2.3/user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java#763
In other words, Restlet still depends on a 18 months old version, namely GWT 2.2: http://code.google.com/p/google-web-toolkit/source/browse/releases/2.2/user/src/com/google/gwt/user/rebind/rpc/SerializableTypeOracleBuilder.java#757
Thanks for reporting this issue. The 2.1 and master branches have been updated.