Compiling Source Files with JAV Extension Myth in Java Language Spec 3.0
Get link
Facebook
Twitter
Pinterest
Email
Other Apps
I' ve read something interesting about java source file extensions at Top level type declarations section in java langugae specification 3.0.
When packages are stored in a file system (§7.2.1), the host system may
choose to enforce the restriction that it is a compile-time error if a type is not
found in a file under a name composed of the type name plus an extension (such
as .java or .jav) if either of the following is true: • The type is referred to by code in other compilation units of the package in
which the type is declared. • The type is declared public (and therefore is potentially accessible from
code in other packages).
While in this paragraph is mentioning about top level type class declarations and source file naming conventions; it is pointing that the java source files could be with file extensions .jav. Immediately, i tried with a sample demo class with name Demo.jav.
Demo.jav
public class Demo {
@Override
public String toString() {
return super.toString() + "\tI am Demo class with jav extension";
}
}
The output is not a surprise and disappointed me :) the source file name is detected as a javac command line flag...
H:\jav source>javac -verbose Demo.jav
javac: invalid flag: Demo.jav
Usage: javac
where possible options include:
-g Generate all debugging info
-g:none Generate no debugging info
-g:{lines,vars,source} Generate only some debugging info
-nowarn Generate no warnings
-verbose Output messages about what the compiler is doing
-deprecation Output source locations where deprecated APIs are used
-classpath Specify where to find user class files
-cp Specify where to find user class files
-sourcepath Specify where to find input source files
-bootclasspath Override location of bootstrap class files
-extdirs Override location of installed extensions
-endorseddirs Override location of endorsed standards path
-d Specify where to place generated class files
-encoding Specify character encoding used by source files
-source Provide source compatibility with specified release
-target Generate class files for specific VM version
-version Version information
-help Print a synopsis of standard options
-X Print a synopsis of nonstandard options
-J Pass directly to the runtime system
I' ve been already using SoapUI Pro 3.6.1 since license expires. Previous migrations to soapUI newer versions had not caused problems but when starting using SoapUI 4.5.0(free) version resulted destroying existing projects. I checked log file ("C:\...\SmartBear\soapUI-4.5.0\bin\soapui.log") and realised that something went wrong about encoding of soapUI project XMLs. Turkish language characters in wsdl files are located in soapUI project XMLs and they are violating cp1254 character convention and causes below exception log. java.io.CharConversionException: Malformed UTF-8 character: 0xc5 0x3f at org.apache.xmlbeans.impl.piccolo.xml.UTF8XMLDecoder.decode(UTF8XMLDecoder.java:80) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader$FastStreamDecoder.read(XMLStreamReader.java:762) at org.apache.xmlbeans.impl.piccolo.xml.XMLStreamReader.read(XMLStreamReader.java:162) at org.apache.xmlbeans.impl.piccolo.xml.PiccoloLexer.yy_refill(PiccoloLexer.java:3474) at org.apac
Early in the morning, I hit this issue because of putting my nose into boot options. I changed the option form AHCI to RAID then restart but what I see flood of "COMRESET failed (errno=-32)" errors. I immediately restart and rollback my action but this doesnt prevent me from falling into desperate flow of error logs in /var/log/syslog. To solve problem, I make my talisman: used screwdriver to remove dvdrom. Because some ubuntu forum posts mentioning the reason is poor SATA cable connection. In my laptop there is no cable but there is a socket to easily remove dvdrom. Anyway after removing, start the system and EUREKA the problem logs are gone! I checked mounted disks and validate reading and writing data is ok with some consequent restarts. Then of course I didnt leave the dvdrom empty. I shutdown the system and stick it into place roughly. And now everyone is allright. The lesson do not touch (mess up with) anything if it is working. :) Aug 10 08:25:09 msi kernel:
SoapUI satisfies the need of testing service oriented applications with test suites that depends on client scenarios. SoapUI enhances its test suite facility with Groovy scripts to create dynamic properties that helps functional testing. The example in soapUI website demonstrates how to retrieve current date in xsd:date format (yyyy-MM-dd). I am not very keen on Groovy but after a bit effort, i implemented this code snippet that returns the current date in xsd:dateTime format. I hope it helps... def dateTimeFormat = "yyyy-MM-dd'T'hh:mm:ss'Z'" def timeZone = TimeZone.getTimeZone("Etc/GMT") def dateTimeFormatter = new java.text.SimpleDateFormat(dateTimeFormat) dateTimeFormatter.setTimeZone(timeZone) return dateTimeFormatter.format(new java.util.Date()) SoapUI DataGen Test Suite Facility SoapUI is not only sending-receiving soap messages, great testing environment tools and Groovy script support makes it valueble.Do not commit any implementation