Richard, This would effectively result in Java code translated directly to Scala, pretty naively. >From what you describe, you have already manually done much better than that.
As you have already hinted at in your previous posts, one of the key points of this would be to take advantage of the fantastic features (OO & functional) of Scala, rather than effectively implementing Java idioms in Scala. Regards - Cemal jWeekend Training, Consulting, Development http://jWeekend.com On 5 January 2011 23:23, richard emberson <richard.ember...@gmail.com> wrote: > So there is an IDE that you can point at a directory tree and > tell it to convert all of the Java files to Scala files. > Does it do a 100% conversion, 90%, 50% or 10% (on average)? > Do you have a link to a page documenting this feature? > > Thanks > Richard > > On 01/05/2011 03:04 PM, Gerolf Seitz wrote: >> >> It's cmd+shift+G (OSX) and it works quite well ;) >> >> On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee<evancho...@gmail.com> wrote: >> >>> You can paste a java class into a .scala file and it'll autoconvert. >>> there's a shortcut keystroke, too, but i don't remember what it is. >>> >>> On Wed, Jan 5, 2011 at 10:40 AM, richard emberson< >>> richard.ember...@gmail.com> wrote: >>> >>>> No IDE, I use Vim. Also, my build environment is Ant-based >>>> using scalac and javac. >>>> >>>> Of course, what I was doing was porting from Java to Scala. >>>> To that end I've got some 400 Vim scripts that aid in the >>>> port. For instance, >>>> >>>> :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g >>>> >>>> converts >>>> final B a[] = >>>> to >>>> val a: Array[B] = >>>> >>>> I don't know if IDEs provide such scripting with regex support. >>>> Also, with a simple Vim script and key combination, I can be >>>> viewing a ported Scala file and jump to its corresponding source >>>> Java Wicket file - very useful when porting or debugging. >>>> Yea, IDEs can do stuff me and my Vim scripts can not do, but my >>>> fingers know Vim. >>>> >>>> I also built a JUnit driver class in Scala (and Java) that allowed >>>> me to execute a single test method in a given test class by setting >>>> two properties in a file that my Ant script reads. This was vital >>>> for hunting down bugs. >>>> >>>> I looked into the tool that allowed Vim to be the front-end and >>>> Eclipse to run in server mode which allows a Vim user to access >>>> many of the extra features the IDE offers, but, as of a couple of >>>> months ago, there was no Scala support in the tool. >>>> >>>> The father of Scala, Martin Odersky uses Emacs. >>>> >>>> Richard >>>> >>>> >>>> >>>> On 01/05/2011 12:38 AM, Juergen Donnerstag wrote: >>>> >>>>> Cool. May I ask which tools (IDE) you've been using and what your >>>>> experience with these tools has been. >>>>> >>>>> -Juergen >>>>> >>>>> On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson >>>>> <jer...@wickettraining.com> wrote: >>>>> >>>>>> On Tue, Jan 4, 2011 at 5:15 PM, richard emberson< >>>>>> richard.ember...@gmail.com >>>>>> >>>>>>> wrote: >>>>>>> >>>>>> >>>>>> Dev Wicketers, >>>>>>> >>>>>>> What: I have ported Wicket to Scala >>>>>>> A couple of months ago I took a 1.5 snapshot and ported to Scala. >>>>>>> This encompasses all of the source and test code. As successive >>>>>>> 1.5 >>>>>>> snapshots were released, I ported those differences to my Scala >>>>>>> version. I am current with 1.5 M3. >>>>>>> >>>>>>> The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not >>>>>>> counting all the println statements I put into the Scala code >>>>>>> for debugging). I used cloc (http://cloc.sourceforge.net/) to >>>>>>> count lines of code. >>>>>>> >>>>>>> >>>>>> I haven't used CLOC before. I've used Ohcount ( >>>>>> http://www.ohloh.net/p/ohcount) and like it. I'll have to give this a >>>>>> try. >>>>>> >>>>>> >>>>>> I have also replaced all of the Java collection classes with >>>>>> >>>>>>> Scala collection classes (though a small number of Java collection >>>>>>> classes remain that did not have comparable Scala >>>>>>> implementations). >>>>>>> >>>>>>> I have changed many method return types from the Java returning >>>>>>> some "object" or "null" to Scala returning "Some(object)" or >>>>>>> "None" >>>>>>> (using the Scala Option[return-type] construct) - trying to >>>>>>> eliminate nulls. >>>>>>> >>>>>>> Lastly, I pushed the IModel[T] typing down to the Component class >>>>>>> making get/set DefaultModel and get/set DefaultModelObject strong >>>>>>> typed. This included using Scala companion object apply methods >>>>>>> which eliminated having to explicitly declare type parameters in >>>>>>> most end-user code (I had read that one of the objections to >>>>>>> pushing strong typing down to the Component class in Wicket was >>>>>>> that there were "too many notes", end-user code was too verbose). >>>>>>> >>>>>>> It can not interoperate with Java Wicket because Scala compiles to >>>>>>> JVM class files and so all of the classes in Java Wicket also >>>>>>> appear in Scala-Wicket. >>>>>>> >>>>>> >>>>>> >>>>>> I have an "internal" name for my Scala port of Wicket which >>>>>>> >>>>>>> acknowledges its Wicket heritage as well as advertises its >>>>>>> enterprise level capabilities. For external communications, >>>>>>> I am currently simply call it Scala-Wicket. >>>>>>> >>>>>>> Why: Scala is a better Java >>>>>>> I was introduced to Scala 9 months ago and quickly determined that >>>>>>> it was a better Java (at least IMO). For Scala to succeed it >>>>>>> requires more programmers to use it. Many on the Scala mailing >>>>>>> lists were from a functional background and seemed not to >>>>>>> recognize >>>>>>> that Haskell and Lisp are not blindingly successful but, rather, >>>>>>> niche languages and that the heavy selling of Scala's function and >>>>>>> typing capabilities might turn off Java programmers. >>>>>>> >>>>>>> Scala struck me in many ways as a strong-typed JavaScript, at >>>>>>> least, much of the code did not have to have type declarations >>>>>>> because the compiler could infer types in many cases. In addition, >>>>>>> a whole lot of the Java boil-plate code was not needed. As such, >>>>>>> it could be sold as simply a better Java; a more-to-the-point >>>>>>> object oriented language with functional programming in-the-small. >>>>>>> >>>>>>> To get more Java programmers to try Scala I looked for a >>>>>>> significant Java application with a strong support and user >>>>>>> community that I could port to Scala. I ended up with Wicket. >>>>>>> Wicket is an enterprise level web framework (unlike existing >>>>>>> Scale web frameworks which place restrictions on enterprise IT >>>>>>> organizations, e.g., by requiring sticky sessions). It is well >>>>>>> documented. And, as it turned out, very, very importantly it had >>>>>>> a large number of unit tests (the unit tests saved my butt, >>>>>>> without them I would never had succeeded in getting a port that >>>>>>> worked). >>>>>>> >>>>>>> No, Really, Why: >>>>>>> I like Scala and I took the time to learn it. Right now about >>>>>>> 20% of programmers use Java while only some 0.4% use Scala. >>>>>>> I did not want my effort of learning Scala to be wasted so my >>>>>>> solution is to increase the number of Scala programmers. Where >>>>>>> to get them? Again, my solution is from the existing horde of >>>>>>> Java programmers. >>>>>>> >>>>>>> Plans: Release, Evolve and Proselytize >>>>>>> I would like to release Scala-Wicket. >>>>>>> I do not know if Apache hosts anything other than Java code. >>>>>>> Growing a community is important. >>>>>>> >>>>>>> Still Todo: >>>>>>> Comments: All of the existing class and inline comments are >>>>>>> still Java related. This would have to be a long, >>>>>>> on-going >>>>>>> task to edit the comments so they reflect the code's >>>>>>> Scala usage. >>>>>>> Package path: The code still uses the "org.apache.wicket" >>>>>>> package path and this must be changed - unless this became >>>>>>> an Apache project. >>>>>>> Author: I have quite literally looked at and touched every >>>>>>> line >>>>>>> of code but I have not yet felt comfortable with adding >>>>>>> myself as an author since, well, many changes were >>>>>>> syntactic and not semantic. >>>>>>> Refactor with Traits: Currently the port uses Scala traits >>>>>>> like >>>>>>> Java interfaces but it should be possible to factor the >>>>>>> common code out into the traits. This would result in many >>>>>>> of the interfaces, the "I" files, such as IModel.scala, >>>>>>> going away. >>>>>>> Some general refactoring: >>>>>>> As an example, consider factoring out the IModel[T] from >>>>>>> Component. Half the time a user wants a Component with >>>>>>> no model, so, if there was a HasModel trait: >>>>>>> class Model[T](var value: T) { >>>>>>> def getObject: T = value >>>>>>> def setObject(value: T): Unit = this.value = value >>>>>>> } >>>>>>> trait HasModel[T] { >>>>>>> var model: Model[T] >>>>>>> def getDefaultModel: IModel[T] = model >>>>>>> def setDefaultModel(model: IModel[T]): this.type = { >>>>>>> .... >>>>>>> this >>>>>>> } >>>>>>> def getDefaultModelObject: Option[T] = { >>>>>>> .... >>>>>>> } >>>>>>> def setDefaultModelObject(obj: T): this.type = { >>>>>>> .... >>>>>>> this >>>>>>> } >>>>>>> } >>>>>>> The Component hierarchy would have no model support. >>>>>>> The user could add model support when needed: >>>>>>> val form = new Form("hi") >>>>>>> with HasModel[Int] { var model = new Model(42) } >>>>>>> Just an Idea. >>>>>>> STM: There are a number of Scala STM projects and I do not >>>>>>> know >>>>>>> if it is useful to add STM capabilities to Scala-Wicket. >>>>>>> RBAC: I've written a Scala implementation of the NIST RBAC >>>>>>> recommended standard and might consider adding it. >>>>>>> Logging: Adding a Scala-based logging framework to aid user >>>>>>> debugging. >>>>>>> Monitoring and stats: In the last couple of years many web >>>>>>> sites have added monitoring and statistics gathering >>>>>>> capabilities (e.g., who clicks what, where, how long, on >>>>>>> what page does the visitor exit the web site, etc.) in >>>>>>> order to know how the web site is being used and then >>>>>>> improve the web site. >>>>>>> Significant Memory Usage Reduction: I've an idea that would >>>>>>> significantly decrease the memory usage of Scala-Wicket >>>>>>> and >>>>>>> I plan to do a test implementation. >>>>>>> Replace Java features: There are still some Java-isms that can >>>>>>> be replaced with Scala equivalents. >>>>>>> Port additional Java Wicket libraries to Scala. >>>>>>> Enable multiple instances of a unit tests to be run at once. >>>>>>> More: ???????????? >>>>>>> >>>>>>> I want to avoid using some of the WTF features of Scala (when a >>>>>>> Java programmer looks at the code and says "WTF") in order to >>>>>>> ease and accelerate acceptance by Java programmers; as >>>>>>> examples, implicits can make code hard to understand and >>>>>>> advanced Scala type usages, as James Gosling said, "makes >>>>>>> one's >>>>>>> head spin". >>>>>>> >>>>>>> >>>>>>> Help and Advice: How should Scala-Wicket be extended and released >>>>>>> >>>>>>> Scala-Wicket is a port and evolution of Wicket, not a ground-up >>>>>>> re-write. Given that, what would you do differently in Wicket >>>>>>> now that there are years of experience using it? >>>>>>> >>>>>>> How best to get a hosting site, release the code and build a >>>>>>> community? >>>>>>> >>>>>>> >>>>>> If you're looking for a place to host it, I'd recommend starting with >>>>>> Github. Git is where the crowd is headed, and Github is the easiest >>>>>> place >>>>>> to get up and running with it these days. >>>>>> >>>>>> You mentioned earlier the idea of it being an Apache project. If you >>>>>> wanted >>>>>> it to be an Apache project, you would start at the Incubator ( >>>>>> http://incubator.apache.org/). The one barrier you'll have initially >>> >>> is >>>>>> >>>>>> that Apache favors "community over code"... so it's not a great place >>> >>> to >>>>>> >>>>>> start a one-man project. Since this is a port of an existing Apache >>>>>> project, you might have more leniency, but you'd have to build a >>>>>> community >>>>>> around the project before you could ever "graduate" from the >>>>>> incubator. >>>>>> >>>>>> Probably Github is your best bet for now. Build a community. Then, >>>>>> if >>>>>> your >>>>>> community is in favor, move to Apache. By that time, ASF might have >>> >>> full >>>>>> >>>>>> git support. >>>>>> >>>>>> >>>>>> Are there any mechanism to help fund such an open-source project? >>>>>>> >>>>>>> >>>>>> Best bet is to build a community. Of course, if you can find some >>>>>> company >>>>>> that wants such a project, you can get monetary support to develop / >>>>>> maintain. But that seems unlikely in this case with the limited >>>>>> number >>>>>> of >>>>>> companies looking for Scala out there, and especially since this is an >>>>>> unproven port of a large Java project. So, start by getting folks >>>>>> like >>>>>> jWeekend involved - great coders who are already salivating for Scala. >>>>>> Find >>>>>> other individuals such as yourself who are interested, and build a >>> >>> group >>>>>> >>>>>> of >>>>>> core committers. >>>>>> >>>>>> >>>>>> This is not meant to be a general announcement but rather a means >>>>>>> >>>>>>> for me to get some initial advice as to how to proceed. >>>>>>> >>>>>>> Any help is appreciated. >>>>>>> >>>>>>> Richard Emberson >>>>>>> >>>>>> >>>>>> >>>>>> I'm impressed. Quite an undertaking. >>>>>> >>>>>> -- >>>>>> Jeremy Thomerson >>>>>> http://wickettraining.com >>>>>> *Need a CMS for Wicket? Use Brix! http://brixcms.org* >>>>>> >>>>>> >>>>> >>>> -- >>>> Quis custodiet ipsos custodes >>>> >>> >> > > -- > Quis custodiet ipsos custodes >
