Java 8
danfickle opened this issue · 12 comments
I've started a java8 branch to see if we can clean up some of the boilerplate by using Java 8 features. Any objections to making this the master branch?
Not an objection, but just a thought: Merging the change to w3c DOM first might be a good idea (if you agree with the change and after some testing of course). Otherwise, maintaining two major branches would be a lot of work.
I'm not sure of the benefits of moving towards using the w3c DOM if you are not using it to pass to the javascript layer. I think the correct approach may be to use our own abstraction over the top of Jsoup or w3c dom making it easier to swap between them based on need. What do you think?
My thoughts:
In Java land, an alternate DOM class hierarchy, such as that provided by JSoup, is not inter-operable with other Java libraries because of strong and static typing. There are many Java libraries out there that work with w3c DOM.
From the perspective of Javascript, it doesn't really matter which library is used because it is weak and dynamically typed. As long as it looks and walks like a duck, JS will quack along.
About abstraction, I don't think a new one is required because the w3c DOM is infact just such an abstraction. It is just a bunch of Interfaces that any one can implement. If we were to make a simple one-line modification to jsoup classes to implement the corresponding w3c Interface, it would work fine (in majority of cases).
I've decided to stick with Java 7 for now, until the cloud support for Java 8 is better.
I see you are on Java 8 again ;) This means that it might take a while for me (and I am sure others) to be able to use it, as Java 6/7 is still what's out there right now. In my case I usually depend on what customers are using, so I don't have full control.
Funnily enough, moving to Scala brings much bigger benefits and doesn't impact the runtime choice at all. Even the recent Scala 2.11 still works on Java 6 (Scala 2.12 will also require Java 8, but that will be out in 1.5-2 years). We made the jump to Scala in 2010 and we have never looked back.
I don't mean the above as severe criticism but I just wanted to say that requiring Java 8 right now can be a drawback. It probably won't be an issue in 2-3 years.
If neoFlyingSaucer only uses Java 8's lambdas, it is possible to support Java 5, 6, 7 with the help of a drop-in library: retro lambda.
Not sure about other Java 8 features, like default methods.
Oops! Just noticed that retro-lambda isn't a library.
I would like to second @ebruchez comment about it taking a while to migrate to SE 8. Most Java applications are on are 6 and 7 and likely wont be upgraded for at least few more years. I would find it very unfortunate if this project moved to java 8 only as it would render it practically unusable for me and im sure many others.
OK, I think the solution is to have a Java 6 branch. I'll start work on it as soon as I finish incorporating the new pdf library. Thanks for the input.
The master branch is now back at Java 6.
Cool, thanks!
And by the way I realize how painful going back to Java 6 might feel ;)