On Fri, 02 Sep 2016 15:49:36 +0200, Tibor Digana
<[email protected]> wrote:
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.
I'm going to end this part, since it is completely off topic.
Start it again in a separate thread if you want, but not here.
I'll rephrase the question: What to do which projects who want to have
their code compatible with a version lower than Java 9 AND want to provide
a module-info file as well?
Robert
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
