I need a way for Maven to set a version number readable in the trunk

[Steve Lewis [e-mail] [seajug]]

I have a Maven project that I am developing with IntelliJ. There is a class
which reads a version from a resource.

public class Version {

public static final String SNAPSHOT = "BAD_VERSION";
public static String version = SNAPSHOT;

static {
// get the location of version property file
URL versionPropertyFileUrl =
Version.class.getClassLoader().getResource("version.properties");

// load version property file
final Properties versionProperties = new Properties();
try {
versionProperties.load(new FileInputStream(new
File(versionPropertyFileUrl.toURI())));
final String property =
versionProperties.getProperty("algorithm.version");
if (!property.startsWith("$")) {
version = property;
}
} catch (Exception e) {
version = SNAPSHOT;
}
}
}

The version.properteis looks like this
algorithm.version = ${artifact.artifactId}-${artifact.baseVersion}

The problem is that a release build sees the correct version but if I run
in the debugger I get BAD_VERSION -

Is there a way to get Maven or some other build process to update the
resource in the trunk so that each run from the trunk at least shows the
version as the last tagged version??

[Jeff Ramsdale [e-mail] [seajug]]

If you put the following in your pom:

<build>
<resources>
<resource>
<directory>src/main/resources/filtered</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>

And in the src/main/resources/filtered directory you put a file with
contents like this:

artifactId=${project.artifactId}
groupId=${project.groupId}
artifactVersion=${project.version}


then the variables in the property file will be resolved by Maven and the
file with resolved contents will be in target/classes and loadable by your
class loader and built into your artifact.

-j

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
I have a Maven project that I am developing with IntelliJ. There is a

class which reads a version from a resource.

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
public class Version {
public static final String SNAPSHOT = "BAD_VERSION";
public static String version = SNAPSHOT;
static {
// get the location of version property file
URL versionPropertyFileUrl =

Version.class.getClassLoader().getResource("version.properties");

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
// load version property file
final Properties versionProperties = new Properties();
try {
versionProperties.load(new FileInputStream(new

File(versionPropertyFileUrl.toURI())));

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
final String property =

versionProperties.getProperty("algorithm.version");

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
if (!property.startsWith("quot;)) {
version = property;
}
} catch (Exception e) {
version = SNAPSHOT;
}
}
}
The version.properteis looks like this
algorithm.version = ${artifact.artifactId}-${artifact.baseVersion}
The problem is that a release build sees the correct version but if I run

in the debugger I get BAD_VERSION -

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
Is there a way to get Maven or some other build process to update the

resource in the trunk so that each run from the trunk at least shows the
version as the last tagged version??

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
--
Steven M. Lewis PhD
4221 105th Ave NE
Kirkland, WA 98033
206-384-1340 (cell)
Skype lordjoe_com

[Konstantin Ignatyev [e-mail] [seajug]]

That works but I personally do not like this way of determining version
numbers. Reason: versions should be assignable externally based on results
of tests _without_ altering artifact in any way.

For example, when we produce artifact-<timestamp>.jar/war, then test this
build and determine that it is good for production deployment I would like
to assign version without rebuilding artifact.

Post by Jeff Ramsdale jeff.ramsdale-***@public.gmane.org [seajug]
<build>
<resources>
<resource>
<directory>src/main/resources/filtered</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
And in the src/main/resources/filtered directory you put a file with
artifactId=${project.artifactId}
groupId=${project.groupId}
artifactVersion=${project.version}

then the variables in the property file will be resolved by Maven and the
file with resolved contents will be in target/classes and loadable by your
class loader and built into your artifact.
-j

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
I have a Maven project that I am developing with IntelliJ. There is a

class which reads a version from a resource.

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
public class Version {
public static final String SNAPSHOT = "BAD_VERSION";
public static String version = SNAPSHOT;
static {
// get the location of version property file
URL versionPropertyFileUrl =

Version.class.getClassLoader().getResource("version.properties");

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
// load version property file
final Properties versionProperties = new Properties();
try {
versionProperties.load(new FileInputStream(new

File(versionPropertyFileUrl.toURI())));

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
final String property =

versionProperties.getProperty("algorithm.version");

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
if (!property.startsWith("quot;)) {
version = property;
}
} catch (Exception e) {
version = SNAPSHOT;
}
}
}
The version.properteis looks like this
algorithm.version = ${artifact.artifactId}-${artifact.baseVersion}
The problem is that a release build sees the correct version but if I

run in the debugger I get BAD_VERSION -

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
Is there a way to get Maven or some other build process to update the

resource in the trunk so that each run from the trunk at least shows the
version as the last tagged version??

Post by Steve Lewis lordjoe2000-***@public.gmane.org [seajug]
--
Steven M. Lewis PhD
4221 105th Ave NE
Kirkland, WA 98033
206-384-1340 (cell)
Skype lordjoe_com

--
Konstantin Ignatyev

PS: If this is a typical day on planet Earth, humans will add fifteen
million tons of carbon to the atmosphere, destroy 115 square miles of
tropical rainforest, create seventy-two miles of desert, eliminate between
forty to one hundred species, erode seventy-one million tons of topsoil,
add 2,700 tons of CFCs to the stratosphere, and increase their population
by 263,000

Bowers, C.A. The Culture of Denial: Why the Environmental Movement Needs a
Strategy for Reforming Universities and Public Schools. New York: State
University of New York Press, 1997: (4) (5) (p.206)

[Jason Osgood [e-mail] [seajug]]

While reading up on Apple’s new Swift language, this bit about call by value popped out. Emphasis mine.

http://graydon2.dreamwidth.org/5785.html

“...it relies on the value/reference type dichotomy like C#. This is a half-way step to regaining some of the performance you lose moving to an all-heap system like Java (note: Java is toying with value types now too) without having the cognitive and design load of explicit pointers."


Oh. I didn’t get that memo.

JEP 169: Value Objects

http://openjdk.java.net/jeps/169

It’s being called VALJO, aka Value Java Objects.

http://blog.joda.org/2014/03/valjos-value-java-objects.html

Time for another mea culpa: Escape analysis didn’t work out like I had hoped. Apparently in the face of separate compilation, it’s an intractable problem. That object can be locked by just about any body.

http://cr.openjdk.java.net/~jrose/values/values-0.html

[While I’m typing this, George is emphatically relating to me that the root problem is the dynamic class loader, vs monolithic compilation. I’ll let him reply with his points.]

###

[Joe Bowbeer [e-mail] [seajug]]

In anticipation of value types in Java 9, there is some language in the
Java 8 doc. See Optional, for example.

While reading up on Apple’s new Swift language, this bit about call by
value popped out. Emphasis mine.
http://graydon2.dreamwidth.org/5785.html
“...it relies on the value/reference type dichotomy like C#. This is a
half-way step to regaining some of the performance you lose moving to an
all-heap system like Java (note: *Java is toying with value types now too*)
without having the cognitive and design load of explicit pointers."
Oh. I didn’t get that memo.
JEP 169: Value Objects
http://openjdk.java.net/jeps/169
It’s being called VALJO, aka Value Java Objects.
http://blog.joda.org/2014/03/valjos-value-java-objects.html
Time for another mea culpa: Escape analysis didn’t work out like I had
hoped. Apparently in the face of separate compilation, it’s an intractable
problem. That object can be locked by just about any body.
http://cr.openjdk.java.net/~jrose/values/values-0.html
[While I’m typing this, George is emphatically relating to me that the
root problem is the dynamic class loader, vs monolithic compilation. I’ll
let him reply with his points.]
###

[Jason Osgood [e-mail] [seajug]]

Hi Joe Bowbeer.

In anticipation of value types in Java 9, there is some language in the Java 8 doc. See Optional, for example.

Huh. Good to know there’s a plan.

I don’t understand Optional. I get the how, but not the why.

And I really don’t like the ? operator for method chaining. e.g. instance.?gimmeWater().?gimmeToast().?gimmeMoney();

I’m comfortable with the Null Object pattern. Composite + Null Object design patterns FTW. My implementations are always concise, resilient, and easy to debug.

Thinking about all this non-null / nullable stuff, I think maybe I’d rather see some syntactic sugar for Null Object definitions, to reduce boilerplate code.

I haven’t divined any proposals yet though, so it’s not a fair criticism.


Cheers, Jason

[George Smith [e-mail] [seajug]]

My goal is that should Value Types be introduced to Java, that a method
that accepts an object shouldn't care if it is a Heap / Value object.

To that end, I want to enable Value Types, but preserve the use of legacy
"source" code.

My point re dynamic class loading, is that if a compiler could do escape
analysis, it could determine when and where to simply make your objects
Value Objects, but with the late binding of dynamic class loading, the
"compiler" can not know where or how a class will be used!

Thanks to Jason for pointing out that one of the major problems with making
an object "automatically" a value type, is that of the Thread Monitor on
each object, and "our" (Java Dev's) assumption that the "pass-by-value of
the reference" facilitates locking (and equality). So...

My suggestions:

- Immutable (Interface preferred or Annotation),
- EqualsContract (Interface),
- NoSynchronize (Interface), &
- ValueType (Convenience Interface that is all the above).

The "Immutable" marker (interface) would cause the "compiler" to make all
fields final and limit the fields to also be Immutable (of primitive).

The "EqualsContract" marker interface would cause the "compiler" to switch
the "equals" and "hashcode" methods to "abstract" forcing implementation
(IMO they should NOT have been included in Object, as it violates the
specific contract given in an Interface - as do the wait/notify, toString
and clone methods).

The "NoSynchronize" interface would cause the "compiler" to disallow
"synchronized" (non-static) methods and disallow "synchronized( this)"
blocks, and the run-time to throw a run time exception if a lock was
attempted on the instance or any of the wait/notify methods were called.

IMO, if a class implements all three interfaces (Immutable, EqualsContract,
& NoSynchronize), then the "compiler" could do some local escape analysis
and determine to switch to a "pure" Pass By Value (stack instance).
Obviously, should some method "save" the passed stack instance, it would
need to be copied to the Heap.

Even w/o the work of implementing the "pure" Pass By Value (stack instance)
support, IMO, the interfaces (and their non-stack instance behavior) would
be good additions to the language!

George

While reading up on Apple’s new Swift language, this bit about call by
value popped out. Emphasis mine.
http://graydon2.dreamwidth.org/5785.html
“...it relies on the value/reference type dichotomy like C#. This is a
half-way step to regaining some of the performance you lose moving to an
all-heap system like Java (note: *Java is toying with value types now too*)
without having the cognitive and design load of explicit pointers."
Oh. I didn’t get that memo.
JEP 169: Value Objects
http://openjdk.java.net/jeps/169
It’s being called VALJO, aka Value Java Objects.
http://blog.joda.org/2014/03/valjos-value-java-objects.html
Time for another mea culpa: Escape analysis didn’t work out like I had
hoped. Apparently in the face of separate compilation, it’s an intractable
problem. That object can be locked by just about any body.
http://cr.openjdk.java.net/~jrose/values/values-0.html
[While I’m typing this, George is emphatically relating to me that the
root problem is the dynamic class loader, vs monolithic compilation. I’ll
let him reply with his points.]
###

[Jason Osgood [e-mail] [seajug]]

The "Immutable" marker (interface) would cause the "compiler" to make all fields final and limit the fields to also be Immutable (of primitive).

I thought we agreed user defined types / classes were immutable by default? So we’d add Mutable (marker interface) to make properties read/write.

Remember ThoughtWorks influence during the early days of Java? Coming from C, I was very impressed with their articles about canonical object. And I remain unhappy that every subclass of Object carries around stuff that’s mostly unused, and often error prone.

I’d love a new class / value hierarchy that separated the canonical object into:

Identity
Mutable
Equality (equals, hashCode)
Comparable
Cloneable
Renderable (toString)

Note the absence of serialization. That’s best done separately, e.g. kyro or protobuf libs.

Even w/o the work of implementing the "pure" Pass By Value (stack instance) support, IMO, the interfaces (and their non-stack instance behavior) would be good additions to the language!

Another (potential) benefit was packed objects (in memory). You may recall the Wing Ding where we were memory profiling XML DOMs. The overhead in Java is pretty brutal. I anticipate a lot of enthusiasm for VALJOs across domains.


Cheers, Jason

[George Smith [e-mail] [seajug]]

Just to re-iterate: Backwards compatibility!

Making classes default to Immutable would break Backwards compatibility!

George

Post by George Smith litesoft-***@public.gmane.org [seajug]
The "Immutable" marker (interface) would cause the "compiler" to make all
fields final and limit the fields to also be Immutable (of primitive).
I thought we agreed user defined types / classes were immutable by
default? So we’d add Mutable (marker interface) to make properties
read/write.
Remember ThoughtWorks influence during the early days of Java? Coming from
C, I was very impressed with their articles about canonical object. And I
remain unhappy that every subclass of Object carries around stuff that’s
mostly unused, and often error prone.
I’d love a new class / value hierarchy that separated the canonical object
Identity
Mutable
Equality (equals, hashCode)
Comparable
Cloneable
Renderable (toString)
Note the absence of serialization. That’s best done separately, e.g. kyro
or protobuf libs.
Even w/o the work of implementing the "pure" Pass By Value (stack
instance) support, IMO, the interfaces (and their non-stack instance
behavior) would be good additions to the language!
Another (potential) benefit was packed objects (in memory). You may recall
the Wing Ding where we were memory profiling XML DOMs. The overhead in Java
is pretty brutal. I anticipate a lot of enthusiasm for VALJOs across
domains.
Cheers, Jason