I am using some library which inside itself use sun.security.* classes. And I'm using it as dependency in my project which is java 8. In java 8 some methods removed from sun classes which my library need.
I understand that messing up with sun.* packages is not good idea, but I don't want to downgrade my project to java 7, so is there any workaround to make my project run in java 8 environment, but use sun.* classes from java 7 ?
... is there any workaround to make my project run in java 8 environment, but use sun.* classes from java 7 ?
The missing method is part of the SSL implementation, and it looks like there have been major rewrites in Java 8. (For good reason, IIRC.)
Is there a simple workaround?
Probably not. It would entail messing around with the SSL implementation, and that is risky, even if you can get the code to run.
A couple of better ideas would be:
Port the 3rd-party library that is causing you problems to Java 8. (Or pay someone else to do it for you.)
Change it to use a different OAuth2 API. There are some leads here: http://oauth.net/2/
Related
I have a doubt about java upgrading
I have applications running in java 6, for example.
And I wanto to upgrade my java to a 7 or 8
My doubt is: What is the best way to upgrade mi current java version?
Or how can I do it?
This applications currently are productive, so this means I has to upgrade the java version witouth affectate it.
I'm very confused about this, hope you can help me
There's only one way to do it:
Upgrade the JVM
Recompile the code and fix any errors that the JVM complains about.
Regression test the code running under the new JVM and make sure the functionality is unchanged.
Take the opportunity to see if there are any advantages to adding new features (e.g. java.time package, lambdas, java.util.function package, etc.)
No one should be running on any JVM other than 8 or 9. JDKs older than 8 have passed the end of their support lives. They are not getting any more security patches.
You are making the excuse that everyone tries when faced with currency issues: "The code is working fine. Why change it?"
Unfortunately there's a price to falling behind.
I'd advise you to upgrade as soon as possible. Stop the excuses.
JDK 9 is the current version. Current or current-1 is usually acceptable; current-3 is not.
Since the release of Java 8, I found myself slowly becoming dependent on Java 8-specific features (ex. lambda statements) on a library project that I have just started.
I have seen many other projects which, to this day, still build against Java 7, or even Java 6, causing me to second-guess myself.
Is it a good idea to immediately start building against the newest version of Java, or should I still use older versions?
Note that unlike those other projects that have started back when Java 6/7 was the newest version, mine was started recently when Java 8 is the newest.
There are two reasons I can think of that would require staying with a pre-Java 8 JVM:
You are writing a library that is being used by a large group of people outside your organization who are still stuck on a pre-Java 8 JVM. If you use the latest and greatest JVM, they won't be able to use your product anymore.
You are dependent on a 3rd party library that has not upgraded to Java 8 and breaks on Java 8.
Since you mentioned this is a new project, #1 is unlikely. Even if you plan on having external users, if it's a new project, requiring the latest version of the JVM isn't really an issue.
Number 2 is also getting more and more unlikely as the more popular 3rd party libraries have released updates to work on Java 8. Even the few stragglers are usually OK working on Java 8. For example I use an ancient version of hibernate with Java 8. I just don't use any Java 8 features in any mapped fields/entities.
Java 8 denotes a major change to the language since Java 5 (or perhaps its inception). If you are targeting specifically the changed language parts (which I guess you claim) then making it usable only by Java 8+ runtime makes sense.
When Java 5 occurred 10 years ago and you wanted to use all the new features introduced at the time (e.g. foreach statement, Enums etc.) into your own library development, what would you have done? I believe you would have made your library require Java 5 at the minimum. If you agree with that, then that (sound) logic applies consistently to your present situation as well.
For server side application, possibly a version or two prior to the current version as suggested by EJP.
On the client side however, I don't see any point in trying to support older Java versions. The JRE has been auto-updating since at least Java 6. It has gotten to the point where Java Web Start launched applications cannot specify an earlier than current JRE. Or rather, it can specify any JRE it chooses in the launch file, but that will be ignored in favor of the latest version installed on the user's computer.
Looking at the documentation for NotNull under Java 7, you can see javax.validation.constraints.NotNull is a valid and documented annotation. However upon navigating to the same page for Java 8, I receive a 404.
Netbeans suggests to import com.avaje.ebean.validation.NotNull, which is not what I want (it doesn't support nearly as many placements).
I've heard of the tag NonNull instead, but I can't find java documentation nor can I import it in netbeans. What am I meant to be using in Java 8?
javax.validation is not part of Java 8, it is part of Java EE, and is still included in Java EE 7
Don't confuse Java SE and Java EE: Differences between Java SE and Java EE.
There is no Java EE 8 yet, it's in planning mode. You can use Jave EE 7's NotNull just fine. Just get the appropriate libraries.
There's obviously no javadoc for a library that doesn't exist, thus the 404 .
Note that specifying an import statement simply makes it possible to refer to types by their simple name rather than by their fully qualified name. It does nothing to actually provide the classes at runtime or compile time. You still need to find the appropriate libraries, possibly packaged as a .jar, and put them on your compile time and runtime classpath, as required.
I'm currently thinking about adding a small part of JSR-310, javax.time.Duration to our library.
This works perfectly fine currently.
But JSR-310 is planned to be integrated in Java 8! When executing our application on Java 8, what will happen if there is both a javax.time.Duration class in the standard library and the same class shipping with our jar file?
Will one of the classes be silently ignored? (Which one?)
Will there be an error when a Java 8 VM tries to load the class from our library?
Are there any compatibility issues I need to be aware of?
The JVM follows the classpath to determine which class to load. If there is more than one, the later classes are silently ignored.
For class included in the JVM itself, these are part of the bootclasspath which is searched before the class path.
Unless there is a breaking change in the API, you shouldn't notice the difference and your extra JAR will effectively be ignored with Java 8.
This issue can now be clarified.
The JDK1.8 classes will be in the java.time namespace, and cannot be overridden (as they are deeply in the core of Java).
A backport project is available that allows a very similar API to be used on JDK1.7. That uses the org.threeten.bp namespace. The idea is that moving forwards to JDK1.8 will simply require a package rename for the most part.
The javax.time namespace is no longer in use.
I am facing an strange issue. I developed java web app in java 6 and when I hosted it on server, its shows error since its java 5 server. I have used annotations, hibernate, rest API in my code and now I want to transform my code with java 5 environment.
is it possible to do so? if yes HOW? Or is there any other workaround for this problem? Please let me know.
#all: This is the error i am getting:
I am not sure what your build process is but you need to compile your code for a specific target like java 1.5.
If you are using javac from the command line look at the -target switch
If you are using ant then look at the target property.
You will run into problems if you are using java 1.6 specific libraries. You will know this when you try and run your code/webapp.
I hope this helps.
You'll have to look at the individual errors and figure out what is missing.
The JPA annotations were already part of Java EE 5, so if "hibernate" is causing problems, it either means you are not in fact running on Java EE 5, or you're using hibernate-specific annotations. The REST annotations were indeed added in Java EE 6, but can be used in a Java EE 5 environment relatively easily by adding a JAR with the API as well as the implementation (e.g. Apache Jersey) to the app's class path.
BTW, there's some confusion here concerning Java SE vs. Java EE. You're clearly talking about Java EE features, but there is a big difference between Java SE (which most people think about when you just say "Java") and Java EE.
From your post, it seems you're using Java EE 6 features in a Java EE 5 environment. If your app. server doesn't support such features at its core level, such as sing Servlet 3.0 features in a Servlet 2.5 environment, then you're out of luck.
However, when using features that are libraries, like Hibernate, you can get away using it in a Java EE 5 environment.
Java 6 as a language remains the same as Java 5, however, libraries have changed. Likewise, using JRE classes and methods that are in 6, won't work in 5.
Update: from your screenshot, I see that you're using Java 6 compiled classes on an older version of Tomcat. Compile them for Java 5.
You are trying to run classes compiled against Java 6 on Java 5 (Tomcat 5.x uses Java 5).
You can upgrade to Java 6.
You can compile the classes to be Java 5 compatible by using "-target" argument to javac but this option is not going to help as the problem is occuring with the servlet api. JEE6 requires Java 6.