Robert, I disagree with you. There is no reason to increase effort only because of one class. Now let's be concrete. I see many managers in commercial firms behave like non-dev managers, and it is horrible in almost every area because now in Europe the political decisions become more important than pragmatical thoughts. So we have to and we are responsible to talk about _why_ and then _how_ and not opposite; otherwise it's just politics. Some people like making release management without coding, some are consultants and not daily coders. That's sad! Every month I am telling to all manager - think of cost and what makes sense. But they don't. They just see themselves and their positions higher and completely forge how harmful it can be to development staff.
On Wed, Aug 31, 2016 at 11:03 PM, Robert Scholte <[email protected]> wrote: > On Wed, 31 Aug 2016 22:02:04 +0200, Tibor Digana < > [email protected]> wrote: > > So, we can try to have different source folders for different runtimes. >>>> >>> No. If you are developers you would not say this. >> No developer would develop and merge the same code multiple times!!! >> Look, now let the maven-compiler-plugin to download jars of the same >> artifact which was released for Version 1.7 and 1.8, and now let the >> compiler wrap those two versions with current version 1.9 which is >> ready to be released. Now you have fat jar MRjar. >> This means any Java version of the artifact can be chosen on the top of >> JDK9. >> >> Most other plugins would need to be executed for each version as well - >>>> javadoc, junit >>>> >>> No. because the previous Versions were already tested and processed. >> >> Again if they *don't* need a separate execution, then why is MRJar needed? >>>> >>> Exactly, and now I cannot imaging company which is going to complicate >> their project with a stupid MRJar and why so if they have WildFly >> 8.2.1 which supports Java 8 do you think they EE project would >> struggle with MRJar? Of course not. If they have WildFly 10.x >> supporting Java 9 then again no developer would build MRJar. >> >> I think MRJar is suitable only for JDK internals and it is only >> because of Oracle has problem with JCP because JCP does not let Oracle >> to break backwards compatibility and introduce dynamic language >> features. So Oracle is trying for compromise. >> Oracle is trying to let you build java.* JDK with javac, interchange >> internal modules, etc. >> Nothing for other non-JDK projects. >> >> > Shared-Utils is a very good candidate for a multirelease jar. > It has a class called Java7Support[1] which uses reflection to make > benefit of Java7 features, otherwise it falls back to Java6. Thanks to > reflection this code is compatible with Java6. > > There are probably more cases, and with the introduction I can imagine > there are projects who will consider to use it. > Even if this is mainly introduced to solve JDK internal issues (I doubt > that this is really true), it is great to see that such feature is also > exposed and available for the Java Community. > > Robert > > [1] https://maven.apache.org/shared/maven-shared-utils/xref/org/ > apache/maven/shared/utils/io/Java7Support.html > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers Tibor
