vlsi commented on code in PR #125:
URL: https://github.com/apache/xalan-java/pull/125#discussion_r1400085032


##########
xalan/src/main/java/org/apache/xalan/Version.java:
##########
@@ -20,36 +20,99 @@
  */
 package org.apache.xalan;
 
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.util.Properties;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+
 /**
  * Administrative class to keep track of the version number of
  * the Xalan release.
  * <P>This class implements the upcoming standard of having
- * org.apache.project-name.Version.getVersion() be a standard way 
- * to get version information.  This class will replace the older 
+ * org.apache.project-name.Version.getVersion() be a standard way
+ * to get version information.  This class will replace the older
  * org.apache.xalan.processor.Version class.</P>
- * <P>See also: org/apache/xalan/res/XSLTInfo.properties for 
+ * <P>See also: org/apache/xalan/res/XSLTInfo.properties for
  * information about the version of the XSLT spec we support.</P>
  * @xsl.usage general
  */
 public class Version
 {
+  private static final String POM_PROPERTIES_JAR = 
"org/apache/xalan/version.properties";
+  private static final String POM_PROPERTIES_FILE_SYSTEM = 
"xalan/target/classes/" + POM_PROPERTIES_JAR;
+  private static final String VERSION_NUMBER_PATTERN = 
"^(\\d+)[.](\\d+)[.](D)?(\\d+)(-SNAPSHOT)?$";
+  private static final String NO_VERSION = "0.0.0";
+
+  private static String version = NO_VERSION;
+  private static int majorVersionNum;
+  private static int releaseVersionNum;
+  private static int maintenanceVersionNum;
+  private static int developmentVersionNum;

Review Comment:
   > The only way around that would be to inline the static helper method 
parseVersionNumber() into the static initialiser block
   
   The method is trivial, so having it inlined does not make the code uglier or 
better. It would be pretty much the same.
   
   Have you considered extracting `Version(...)` record-like class with 
instance `final` fields?
   
   * It would allow `final` fields with a plain Java code without static 
initializer blocks and so on
   * It would make the code easier to test. Well, why not add a unit test or 
two for the regexp in the parsing logic?
   * It would enable reusing the parse logic across "version" classes
   * It might even make the code easier to read
   
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org

Reply via email to