[The Java Posse] Re: Java officially lags C
I use to always put my SQL code in specific files, because I came from ugly
Oracle SQL preprocessor where SQL and code where mixed like hell (JSP files
are the same BTW).
But, today I prefer Named Queries and/or JDBC 4.
I use to declare my ORM mapping and my Depency Injection in a separate XML
file :)
Now I used JPA and JaCaDI (JSR-299 + JSR-330)
Having the SQL query above the method that will execute is a HUGE benefit:
@SQL("select id from datastore where length > :threshold")
Collection getIdsAbove(long threshold);
Clear, easy to debug/modify/refactor and especially extremely clear usage of
what the method is doing.
It's the same for ORM and DI using Annotations vs. XML.
It's hard to have a good balance when mixing languages in the same file, but
when done right it's always a winner.
Clean injection of DSL is the good way to go.
On Thu, Sep 3, 2009 at 3:16 AM, Casper Bang wrote:
>
> Annotations are the recommended way however, as it facilitates
> validation. If you use em.createQuery(...) everything is late-bound
> and even less type checked than using a namedQuery. For SQL though,
> you are absolutely right but sadly SQL is no longer considered trendy.
>
> /Casper
>
> On 3 Sep., 01:53, Jess Holle wrote:
> > Casper Bang wrote:
> > > The issue goes a little deeper than your simple use case though. The
> > > Java enterprise world, due to the lack of expression trees, has to
> > > work with many thousands lines of embedded DSL (JPQL/HQL/SQL etc.).
> > > This poses several problems:
> >
> > > - How do you format/indent it?
> > > - How do you copy-paste between database tool and IDE?
> > > - How do you get help with the syntax?
> >
> > > By my experience, that is very much a real problem :
> >
> > > " select new com.somecompany.somexp.backend.model.ManagerInfoRecord("+
> > > " c, b.itemNo, x )" +
> > > " from SomeEntity x" +
> > > " Join x.account a" +
> > > " Join a.baseData b" +
> > > " Join b.customer c "+
> > > " where x.state <> com.somecompany.somexp.backend.entities.SomeEntity
> > > $ReadingState.InValid " +
> > > " and ( " +
> > > "(" +
> > > " x.someState = com.somecompany.somexp.backend.entities.SomeEntity
> > > $someState.Valid " +
> > > " and b.someData <> 'Y' " +
> > > ")" +
> > > "or x.someOtherState =
> > > com.somecompany.somexp.backend.entities.SomeEntity
> > > $someOtherState.Valid " +
> > > " )" +
> > > " and b.relatedEntity =:relatedEntity " +
> > > " and x.someForeignRelation <>
> > > com.somecompany.somexp.backend.entities.SomeEntity$EntityStateEnum.E
> > > " ),
> >
> > > And that's just one small annotation query (obfuscated to protect the
> > > innocent). Fun eh? :)
> >
> > You don't embed this sort of thing. You use getResourceAsStream() and a
> > separate file along with MessageFormat or such to perform substitutions
> > of live data if need be.
> >
> > Plain and simple.
> >
> > This also allows the IDE to do easily appropriate things for a .sql file
> > or the like.
> >
> > [In the XML sphere I'm all for sticking SVG, XSL FO, etc, directly
> > inside an XHTML document -- but this whole approach seems to be dying on
> > the vine there, even though the grammar is the same throughout all of
> > these.]
> >
> > --
> > Jess Holle
> >
>
--
JFrog Ltd
5 Habonim st., P.O.Box 8187
Netanya, Israel 42504.
Tel: +972 9 8941444
Fax: +972 9 8659977
http://www.jfrog.org/
http://freddy33.blogspot.com/
http://nothingisinfinite.blogspot.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---
[The Java Posse] Re: cucumber in episode #270
As promised, my slides from Agile 2009 are now on SlideShare: http://tinyurl.com/groovy-testing Description: Using the Groovy dynamic language for primarily functional / acceptance / customer / BDD testing with a forward looking perspective. Also considers polyglot options. The techniques and lessons learned can be applied to other kinds of testing and are also applicable to similar languages. Drivers and Runners discussed include: Native Groovy, HttpBuilder, HtmlUnit, WebTest, Watij, Selenium, WebDriver, Tellurium, JWebUnit, JUnit, TestNG, Spock, EasyB, JBehave, Cucumber, Robot Framework and FitNesse/Slim. Cheers, Paul. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Java officially lags C
On Thu, Sep 3, 2009 at 01:53, Jess Holle wrote:
>
> You don't embed this sort of thing. You use getResourceAsStream() and a
> separate file along with MessageFormat or such to perform substitutions
> of live data if need be.
>
> Plain and simple.
Yup. Good idea. So you've now maximally separated definition from
usage, so that when editing one you lose the context of the other. For
even better effect, use a maven project layout and have your .sql file
buried under src/main/resouces while the java code that loads it,
substitutes in variables and calls the data base is in src/main/java.
For extra masochism you could embed your SQL fragments in a nest of
angle brackets.
Sorry, that was harsh, but there is a trade-off being made here which
should be considered.
*way* back in the day, I rewrote a tool to generate Java classes
specific to our business object framework from UML diagrams in
Rational Rose (which had a truly demented almost-clone of VBA
embedded).
The original tool was a hideous sprawl of mile-long print statements
containing a heady mixture of literal string fragments and (mostly
global) variables. It was unreadable.
The first thing I did was write a *very simple* templating system, so
I could put the java code fragments into templates containing named
"substitution points" (i.e. variables, think "${classname}"). Then the
code generator would load up the template by name, perform
substitutions on it by providing name/value pairs and then finally
output the result.
I quickly found that this was tedious, because the code was referring
to names (of substitution points and templates) that I wasn't seeing
while coding. I finally ended just embedding the templates in the
program as comments. (The first thing the script did when starting up,
was load the templates by reading through its own source. Sick, but it
worked well.) That way they were declared close to their point of use
and one could easily refer back and forth while developing and
modifying the program.
Though unconventional, this solution turned out to be a
maintainability win, almost entirely due to the fact that I was able
to keep use and declaration close to each other.
> This also allows the IDE to do easily appropriate things for a .sql file
> or the like.
>
> [In the XML sphere I'm all for sticking SVG, XSL FO, etc, directly
> inside an XHTML document -- but this whole approach seems to be dying on
> the vine there, even though the grammar is the same throughout all of
> these.]
Yea, you'd think that the XML vocabularies out there would be a
natural fit for some kind of literate programming approach, like an
XHTML document which both explains and embeds an XSD along with
tooling to generate human-readable XHTML and machine-readable XSD from
the combined doc.
But, sadly, not so much of that going on.
// Ben
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~--~~~~--~~--~--~---
[The Java Posse] Re: Wicket-based A/B testing mechanism
In Wicket, the ordering of containment in the html must map in the code. IMHO, this would make A/B/.../K testing painful unless you component it up the wazoo. On Aug 11, 11:15 am, "Joe Nuxoll (Java Posse)" wrote: > Not sure if this is built directly into Wicket or not... but is there > a good way to do A/B testing using Wicket? Or rather: A/B/C/D/E/F/G/ > H/I/J/K testing? Just looking for thoughts and pointers... > > - Joe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] #277: Not a view from an ivory tower
After listening to episode 277, I'm led to conclude I'm thought of by
some as one of the "ivory tower guys" who "just says no" to ideas
about changing the Java programming language.
I have a rather different perspective.
In November 2006, Sun published javac and related code under the
familiar GPLv2 with Classpath exception. [1]
Shortly thereafter in January 2007, no less a Java luminary than James
Gosling endorsed the Kitchen Sink Language (KSL) project. [2] In
James' words KSL is "A place where people could throw language
features, no matter how absurd, just so that folks could play around"
since he has "... never been real happy with debates about language
features, I'd much rather implement them and try them out."
KSL received no significant community response.
Later in 2007, after the remaining core components of the platform
were published as open source software as part of OpenJDK during
JavaOne, in November Kijaro was created. [4] Kijaro is similar in
spirit to KSL, but not does require contributors to sign the Sun
Contributor Agreement (SCA). Before Project Coin, Kijaro saw a modest
number of features developed, fewer than ten, which is also not a
particular vigorous community response given the millions of Java
developers in the world.
The earliest posts on what would become Project Coin mentioned the
utility of prototypes, the Project Coin proposal form included a
section to provide a link to an optional prototype, and I repeated
stated throughout Project Coin the helpfulness of providing a
prototype along with a proposal.
Despite the availability of the OpenJDK sources for javac and the
repeated suggestions to produce prototypes, only a handful of
prototypes were developed for the 70 proposals sent into Project Coin.
Dick asked rhetorically during the podcast whether alternative
projects exploring language changes were inevitable as the "only
approach given strict control exercised over the JVM [by Sun]."
IMO, such approaches are inevitable only if Sun's repeated efforts to
collaborate continue to be ignored.
Classes on compilers are a core component of many undergraduate
compiler science curricula. All the Java sources in the JDK 7
langtools repository adds up to about 160,000 lines of code and javac
itself is a bit over 70,000 lines currently. These are far from
trivial code bases and some portions of them are quite tricky, but
implementing certain changes isn't that hard. Really. Try it out.
Dick says toward the end of the opening segment "If people do want to
do this stuff, right now they are being told they can't."
I certainly do not have the authority to tell others what they can and
cannot do. Indeed, I have advocated producing prototypes of language
changes as a much more productive outlet than whining and pouting that
other people aren't busy implementing the language changes you want to
little avail. Others have already noted in previous messages to this
group the irony of Lombok using the annotation processing facility I
added to javac in JDK 6 as an alternate way to explore language
changes (together with an agent API to rewrite javac internal
classes!) . However, way back before JDK *5* shipped in 2005, we at
Sun recognized that annotation processors by themselves would be a
possible way to implement certain kinds of de facto language changes.
The apt tool and later javac were always designed to be general meta-
programming frameworks not directly tied to annotations; for example,
an annotation processor can process a type containing no annotations
to, say, enforce a chosen extra-linguistic check based on the
structure of the program.
As an example of what can be done just using annotation processing,
long-time annotation processing hacker Bruce Chapman implemented
"multi-line strings" as part of his rapt project [5]; the value of the
string is populated from a multi-line comment. After repeatedly
outlining how it would be possible to do so on the annotation
processing forum [6], I've gotten around to hacking up a little proof-
of-concept annotation processor based implementation of Properties.
[7] The user writes code like
public class TestProperty extends TestPropertyParent {
protected TestProperty() {};
@ProofOfConceptProperty
protected int property1;
@ProofOfConceptProperty(readOnly = false)
protected long property2;
@ProofOfConceptProperty
protected double property3;
public static TestProperty newInstance(int property1,
long property2,
double property3) {
return new TestPropertyChild(property1, property2, property3);
}
}
and the annotation processor generates the superclass and subclass to
implement the desired semantics, including the getter and setter
methods, etc. Using annotation processors in this way is a bit clunky
compared to native language support, but if people want to experiment,
the capabilities have been standardized as part of the platform since
JDK 6.
[The Java Posse] Re: #277: Not a view from an ivory tower
Thanks Joe. I appreciate this response. Any chance we can get a blog
on it to spread around?
On Sep 2, 2009, at 8:44 PM, jddarcy wrote:
>
> After listening to episode 277, I'm led to conclude I'm thought of by
> some as one of the "ivory tower guys" who "just says no" to ideas
> about changing the Java programming language.
>
> I have a rather different perspective.
>
> In November 2006, Sun published javac and related code under the
> familiar GPLv2 with Classpath exception. [1]
>
> Shortly thereafter in January 2007, no less a Java luminary than James
> Gosling endorsed the Kitchen Sink Language (KSL) project. [2] In
> James' words KSL is "A place where people could throw language
> features, no matter how absurd, just so that folks could play around"
> since he has "... never been real happy with debates about language
> features, I'd much rather implement them and try them out."
>
> KSL received no significant community response.
>
> Later in 2007, after the remaining core components of the platform
> were published as open source software as part of OpenJDK during
> JavaOne, in November Kijaro was created. [4] Kijaro is similar in
> spirit to KSL, but not does require contributors to sign the Sun
> Contributor Agreement (SCA). Before Project Coin, Kijaro saw a modest
> number of features developed, fewer than ten, which is also not a
> particular vigorous community response given the millions of Java
> developers in the world.
>
> The earliest posts on what would become Project Coin mentioned the
> utility of prototypes, the Project Coin proposal form included a
> section to provide a link to an optional prototype, and I repeated
> stated throughout Project Coin the helpfulness of providing a
> prototype along with a proposal.
>
> Despite the availability of the OpenJDK sources for javac and the
> repeated suggestions to produce prototypes, only a handful of
> prototypes were developed for the 70 proposals sent into Project Coin.
>
> Dick asked rhetorically during the podcast whether alternative
> projects exploring language changes were inevitable as the "only
> approach given strict control exercised over the JVM [by Sun]."
>
> IMO, such approaches are inevitable only if Sun's repeated efforts to
> collaborate continue to be ignored.
>
> Classes on compilers are a core component of many undergraduate
> compiler science curricula. All the Java sources in the JDK 7
> langtools repository adds up to about 160,000 lines of code and javac
> itself is a bit over 70,000 lines currently. These are far from
> trivial code bases and some portions of them are quite tricky, but
> implementing certain changes isn't that hard. Really. Try it out.
>
> Dick says toward the end of the opening segment "If people do want to
> do this stuff, right now they are being told they can't."
>
> I certainly do not have the authority to tell others what they can and
> cannot do. Indeed, I have advocated producing prototypes of language
> changes as a much more productive outlet than whining and pouting that
> other people aren't busy implementing the language changes you want to
> little avail. Others have already noted in previous messages to this
> group the irony of Lombok using the annotation processing facility I
> added to javac in JDK 6 as an alternate way to explore language
> changes (together with an agent API to rewrite javac internal
> classes!) . However, way back before JDK *5* shipped in 2005, we at
> Sun recognized that annotation processors by themselves would be a
> possible way to implement certain kinds of de facto language changes.
> The apt tool and later javac were always designed to be general meta-
> programming frameworks not directly tied to annotations; for example,
> an annotation processor can process a type containing no annotations
> to, say, enforce a chosen extra-linguistic check based on the
> structure of the program.
>
> As an example of what can be done just using annotation processing,
> long-time annotation processing hacker Bruce Chapman implemented
> "multi-line strings" as part of his rapt project [5]; the value of the
> string is populated from a multi-line comment. After repeatedly
> outlining how it would be possible to do so on the annotation
> processing forum [6], I've gotten around to hacking up a little proof-
> of-concept annotation processor based implementation of Properties.
> [7] The user writes code like
>
> public class TestProperty extends TestPropertyParent {
> protected TestProperty() {};
>
> @ProofOfConceptProperty
> protected int property1;
>
> @ProofOfConceptProperty(readOnly = false)
> protected long property2;
>
> @ProofOfConceptProperty
> protected double property3;
>
> public static TestProperty newInstance(int property1,
> long property2,
> double property3) {
> return new TestPropertyChild(property1, property2, property3);
> }
> }
>
> and the annotation processor generates the s
[The Java Posse] Re: #277: Not a view from an ivory tower
Thanks for your response to criticisms of the lack of significant new features in Java 7. It is very important to know that there is a ready line of communication between the people who control a language and those who use it. Having said that, could you answer this question... Which of the new features in Java 7 do you think will do most to address the current flow of talented programmers away from Java and to alternative languages (such as Scala, groovy, Python, c#, etc.). Any why? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: #277: Not a view from an ivory tower
As I've communicated to Alex Buckley, I just think the community was surprised by how few resources Sun would/could put on it. Seems like this boils down to a conflict of interest between Sun, the JCP and the people in the trenches. Sun needs to realize how this model appears from a far and how it restricts further adoption beyond the existing momentum. Even if the business model accounted for this already, it will cause harm to Sun's image as entrepreneurs and innovators - deserved or not. So my question would be this: With JavaFX currently being marketed as a fairly narrow RIA technology into a fairly competitive marked, what if it fails to deliver? /Casper On 3 Sep., 14:22, Joshua Marinacci wrote: > Thanks Joe. I appreciate this response. Any chance we can get a blog > on it to spread around? > On Sep 2, 2009, at 8:44 PM, jddarcy wrote: > > > > > After listening to episode 277, I'm led to conclude I'm thought of by > > some as one of the "ivory tower guys" who "just says no" to ideas > > about changing the Java programming language. > > > I have a rather different perspective. > > > In November 2006, Sun published javac and related code under the > > familiar GPLv2 with Classpath exception. [1] > > > Shortly thereafter in January 2007, no less a Java luminary than James > > Gosling endorsed the Kitchen Sink Language (KSL) project. [2] In > > James' words KSL is "A place where people could throw language > > features, no matter how absurd, just so that folks could play around" > > since he has "... never been real happy with debates about language > > features, I'd much rather implement them and try them out." > > > KSL received no significant community response. > > > Later in 2007, after the remaining core components of the platform > > were published as open source software as part of OpenJDK during > > JavaOne, in November Kijaro was created. [4] Kijaro is similar in > > spirit to KSL, but not does require contributors to sign the Sun > > Contributor Agreement (SCA). Before Project Coin, Kijaro saw a modest > > number of features developed, fewer than ten, which is also not a > > particular vigorous community response given the millions of Java > > developers in the world. > > > The earliest posts on what would become Project Coin mentioned the > > utility of prototypes, the Project Coin proposal form included a > > section to provide a link to an optional prototype, and I repeated > > stated throughout Project Coin the helpfulness of providing a > > prototype along with a proposal. > > > Despite the availability of the OpenJDK sources for javac and the > > repeated suggestions to produce prototypes, only a handful of > > prototypes were developed for the 70 proposals sent into Project Coin. > > > Dick asked rhetorically during the podcast whether alternative > > projects exploring language changes were inevitable as the "only > > approach given strict control exercised over the JVM [by Sun]." > > > IMO, such approaches are inevitable only if Sun's repeated efforts to > > collaborate continue to be ignored. > > > Classes on compilers are a core component of many undergraduate > > compiler science curricula. All the Java sources in the JDK 7 > > langtools repository adds up to about 160,000 lines of code and javac > > itself is a bit over 70,000 lines currently. These are far from > > trivial code bases and some portions of them are quite tricky, but > > implementing certain changes isn't that hard. Really. Try it out. > > > Dick says toward the end of the opening segment "If people do want to > > do this stuff, right now they are being told they can't." > > > I certainly do not have the authority to tell others what they can and > > cannot do. Indeed, I have advocated producing prototypes of language > > changes as a much more productive outlet than whining and pouting that > > other people aren't busy implementing the language changes you want to > > little avail. Others have already noted in previous messages to this > > group the irony of Lombok using the annotation processing facility I > > added to javac in JDK 6 as an alternate way to explore language > > changes (together with an agent API to rewrite javac internal > > classes!) . However, way back before JDK *5* shipped in 2005, we at > > Sun recognized that annotation processors by themselves would be a > > possible way to implement certain kinds of de facto language changes. > > The apt tool and later javac were always designed to be general meta- > > programming frameworks not directly tied to annotations; for example, > > an annotation processor can process a type containing no annotations > > to, say, enforce a chosen extra-linguistic check based on the > > structure of the program. > > > As an example of what can be done just using annotation processing, > > long-time annotation processing hacker Bruce Chapman implemented > > "multi-line strings" as part of his rapt project [5]; the value of the > > string is populate
[The Java Posse] Re: #277: Not a view from an ivory tower
All points well taken -- at least by me.
I know what it's like to work as hard as you can towards something and
be shot down by criticism that you're not doing anything or not even trying.
That said, a few points:
* Not all of us are compiler experts -- and javac is fairly large
and gnarly.
* Doing most things involving more than just compilation syntax or
simple changes/additions to core Java classes is rather daunting
in OpenJDK. There were large portions of some presentations at
JavaOne outlining just how hard this is when one has to consider
native and Java code and their memory interactions with GC, etc.
Also, from everything I've heard, OpenJDK is still a rather gnarly
codebase. Being able to open a top-level project in an [ideally
free] IDE on each platform, simply hit "build" and get the same
result as Sun, and have full code completion / navigation data
would be a really helpful starting point... Project Maxine really
struck me as compelling way out of many of these issues -- but it
is in its research infancy and could have been killed for all I
know (I never heard it mentioned by Sun folk at this year's
JavaOne...).
* Neil Gafter certainly availed himself of javac, OpenJDK, etc, and
produced a BGGA prototype. After all of this work, it went
nowhere. Various Sun folk said they simply had no resources to
properly deal with the proposal. This has to make others gunshy
of investing their time and effort.
* There is also a sense that any such effort won't bear fruit for
years -- as JDK development cycles are pretty long, JDK feature
freezes come pretty early, and at least some of us can't actually
/use /any feature until it is available on /all /of our platforms
in a normal released JDK. In my case, this platform mix includes
AIX, which automatically adds at least a year and usually more
beyond Sun's development cycle. [Yes, this is beyond Sun's
control and one of my major gripes with IBM -- that and their lack
of consistency with Sun's JVM implementation.]
* I /desperately /want a "controlled" form of multiple inheritance
in Java ala traits or mixins. The reduction in clumsy hand wiring
to various delegate objects is clear to anyone who has used such
features. Java has always been extremely clumsy in this regard
and this has been clearly evident from day one. This needs to be
fixed! Just because Sun said no to C++'s complex, problematic,
uncontrolled and chaotic multiple inheritance does not mean Java
should throw out the baby with the bathwater! In this case Sun
has repeatedly told me and others "no", with no good reason other
than a dogmatic "multiple inheritance is bad and will never be in
Java". This is madness. Simply allowing something like:
public interface MyTrait
{
public Foo getFoo();
public void operateOnFoo()
{
// default implementation calling getFoo() as needed
}
}
would be huge -- and only requires that interfaces be allowed to
provide implementation [and something like MyTrait.operateOnFoo() in
cases where there is ambiguity between implementations]. One could
also introduce a new contextual keyword of "trait" rather than
"interface" here for clarity, but that seems unnecessary.
Finally, we did discover the ability to auto-generate base classes via
annotation processors. It's not immediately clear that this is possible
from perusing the documentation, but this approach does open up a lot of
doors...
--
Jess Holle
jddarcy wrote:
> After listening to episode 277, I'm led to conclude I'm thought of by
> some as one of the "ivory tower guys" who "just says no" to ideas
> about changing the Java programming language.
>
> I have a rather different perspective.
>
> In November 2006, Sun published javac and related code under the
> familiar GPLv2 with Classpath exception. [1]
>
> Shortly thereafter in January 2007, no less a Java luminary than James
> Gosling endorsed the Kitchen Sink Language (KSL) project. [2] In
> James' words KSL is "A place where people could throw language
> features, no matter how absurd, just so that folks could play around"
> since he has "... never been real happy with debates about language
> features, I'd much rather implement them and try them out."
>
> KSL received no significant community response.
>
> Later in 2007, after the remaining core components of the platform
> were published as open source software as part of OpenJDK during
> JavaOne, in November Kijaro was created. [4] Kijaro is similar in
> spirit to KSL, but not does require contributors to sign the Sun
> Contributor Agreement (SCA). Before Project Coin, Kijaro saw a modest
> number of features developed, fewer than ten, which is also not
[The Java Posse] Re: #277: Not a view from an ivory tower
Joe, I think a very (_very_) large problem with The Kitchen Sink Language, kijaro, and the open sourced JDK is that you fundamentally can't solve your own problem with it. There are exceptions, but the vast majority of java programmers I know of that are interested in developing their own language features use an IDE. The reason is fairly simple; people with the ability to reason about which features they'd want in a programming language rightly think java is beyond cludgy with a dumb editor. They use the smart IDEs - generally eclipse, netbeans or IntelliJ, because those source editors are pretty much the most advanced thing out there, for _any_ programming language. In other words, I firmly believe java would have died a long time ago if it wasn't for the IDEs. It's no accident, either; the way java works means that IDEs can do an extraordinary amount of work for you, far more than in languages such as python, where refactorings use a lot of weak raw string searches and guesswork. All of which is nice, but makes projects like the KSL, kijaro, and even hacking the openJDK code base not particularly useful. Prototypes are always nice, but I honestly cannot get a good feel of a new language feature if I'm forced to program in notepad. That's what makes lombok so different, and that's perhaps why the lombok discussion group already has more posts in it inside of a month than kijaro's in its 2 years. You can actually use it, right now, on your day to day projects, without having to completely change your development environment (including IDE, build scripts, etcetera). Well, not _entirely_, you must be using only eclipse and javac, and various source-based tools like the GWT compiler and even javadoc cannot (yet!!) interpret lombok code. But it's close enough; the pain of having to work around lombok's inadequacies is less than the gain, and that's of course the key factor. I'd also like to state my support for Jess Holle's very astute observation that the first serious attempt to build a fully specced, fully prototyped proposal (BGGA) got a rather lukewarm response from sun. The BGGA proposal didn't just have an excellent spec and prototype behind it, it has received more community support than any proposal I've _ever_ seen in the history of java. All that, and sun still doesn't care? That's a pretty cold shower for anybody else wanting to try what you're suggesting: Building a prototype like you suggest doesn't at the moment seem to make a big difference in the likelyhood of that proposal being selected for inclusion into the JDK. It is certainly why Roel and I built lombok into what it is today; originally we had a plan to build an alternative closure proposal (because, for all the praise Neal ought to receive for his work on speccing out BGGA and building the prototype, I think there's a better way, but that's not very relevant to this discussion), building on neal's prototype, but after the non-result of BGGA, I didn't see how that was going to be useful. To be useful, it had to do at least 1 of the following 2 goals: 1. Make a lot of headway in getting the proposal into the JDK, and/or 2. be usable by myself during my day-to-day programming work. As a prototype so far doesn't seem to accomplish goal #1, and (at least as based on a fork of javac) isn't useful for goal #2, lombok is an eclipse plugin and a javac annotations processor hack instead. On that note, thanks much for the APT API - it's nice. The javac API is also quite clean, I don't really get why Jess thinks the javac code base is 'gnarly'. It's much cleaner than eclipse's ecj. But, let's not get carried away here - lombok only uses a tiny little bit of the APT API. What lombok does is fundamentally not supported by annotation processing. We just use annotation processing as an 'in' - a way to get our code executed so we can break public API contracts and dig into javac's innards. As nice as the annotation processing API is, the cost of being forced to create subclasses is far too great to justify some relatively small improvement as multi-line strings. It's like the pair class: There are a few gazillion Pair implementations out there because the slight benefit of having one is not worth the burden of adding a dependency on a library, and yet, you do want the feature, so people work around it. These language improvements seem similar: For every _SINGLE_ instance where you'd want it, it's not worth the trouble of building an annotation processor and having to deal with generated subclasses, but add up all the times you'd actually use such an improvement, and it's very much worth it. Lombok solves this problem. KSL/Kijaro/OpenJDK don't. -- Reinier Zwitserloot On Sep 3, 4:47 pm, Jess Holle wrote: > All points well taken -- at least by me. > > I know what it's like to work as hard as you can towards something and > be shot down by criticism that you're not doing anything or not even trying. > > That said, a few points: > >
[The Java Posse] Re: #277: Not a view from an ivory tower
Reinier Zwitserloot wrote: > I'd also like to state my support for Jess Holle's very astute > observation that the first serious attempt to build a fully specced, > fully prototyped proposal (BGGA) got a rather lukewarm response from > sun. The BGGA proposal didn't just have an excellent spec and > prototype behind it, it has received more community support than any > proposal I've _ever_ seen in the history of java. All that, and sun > still doesn't care? I know I'm going to raise a can of worms :-) but there are some points that have to be addressed here. It all depends by what "community" means, but the fact that there are blogs praising a certain feature, or even a lot of messages in a mailing list doesn't prove that the majority of the "community" wants that. To be more precise, if you have a lot of people interested in a given project, e.g. Lombok, which is an optional tool for Java, everybody is happy: if you get 100, 1.000, 10.000, 100.000 enthusiasts, your project will have a bright future, and the rest of the Java users (who are millions) who don't know, don't care or don't like it will still live happy. Things are different if one pretend that 1.000 or 10.000 people make a decision to change Java that will affect everybody. My personal experience is that the vast majority of my customers (I'm talking of several firms from small to large) don't give a bit for closures (just to make an example), don't feel they need it, don't feel they like it and are neutral or negative with them. My personal experience with forums or mailing lists of various human activities (not necessarily technological ones) is that they might have thousands of subscribers, while the traffic is lead by tens of them. Thus, any discussion made by those tens of persons can't be deemed of representative of the whole community. *** I don't think that neither blogs or mailing lists are true representative of the reality out there (technological, political, or what else). *** They only make more noise, but the standard rules for democracy are still "one head, one vote", so they only count for themselves. That's why, for instance, to elect a government blogs and such can be thought as influential, but in the end you do count any single vote. As I said, this has to do with how do you define community: people who attend blogs, mailing lists and conferences, or the whole set of users. Of course I reckon that there is a problem with the latter, as we can't measure it. Neither I'm pretending that Sun was right in not accepting BGGA because they allegedly know the wishes or the whole set of users. Neither I can, of course, pretend that I or my customers are representative of the majority. But even if we accept the former definition of community, I think that before declaring that the community wants something, we need some sort of poll that, while shouldn't necessarily be as formal and controlled like an election poll, must be decently structured. For instance, Java.Net polls are not good, figure out if I think that generically quoting bloggers' enthusiasm is good. Given that, I'm not proposing to set up such a poll, because I don't know how to set it up (and nobody says that a technical community is a "democracy" in the strict sense - in fact, it isn't). A good half+ of my customers don't even know or read Java.Net, DZone.com or JavaPosse or attend a JUG, so I wouldn't be able to say how to reach and ask to everybody. I'm only saying that in this situation, I'm all but scandalized if Sun takes decisions such as not putting BGGA or other stuff in the JDK. They can be technically wrong, but I don't think one can prove they are deciding against the community will. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: #277: Not a view from an ivory tower
Funny enough, I just submitted such a poll to java.net since there are certainly more average developers following it, than there are tracking the coin mailing-list. Personally I don't think language design should be a democratic endeavor exactly for the reasons outlined by Joe and Alex, things goes just a little bit deeper than most can fathom. What you *can* find out by asking the community however, is what they struggle with daily and what would excite them. And I should add that my definition of a community does not cover the JCP members who are not really interested in Java per se, but much more interested in profiting on their latest SOA vendor lock-in. So as an engineer interested in improving my day-to-day environment I have only a few options 1) become a cubicle robot and not care about this stuff at all, 2) be a loudmouth and try to push what I feel is good taste in programming, 3) find another job where I can choose a stack that makes me feel productive and passionate again or 4) help in undermining official Java and put my faith in the grassroots of the community i.e. Lombok. Given the relatively mute blogosphere surrounding JDK7, I am probably not the only one contemplating these options. /Casper On 3 Sep., 22:47, Fabrizio Giudici wrote: > Reinier Zwitserloot wrote: > > I'd also like to state my support for Jess Holle's very astute > > observation that the first serious attempt to build a fully specced, > > fully prototyped proposal (BGGA) got a rather lukewarm response from > > sun. The BGGA proposal didn't just have an excellent spec and > > prototype behind it, it has received more community support than any > > proposal I've _ever_ seen in the history of java. All that, and sun > > still doesn't care? > > I know I'm going to raise a can of worms :-) but there are some points > that have to be addressed here. It all depends by what "community" > means, but the fact that there are blogs praising a certain feature, or > even a lot of messages in a mailing list doesn't prove that the majority > of the "community" wants that. To be more precise, if you have a lot of > people interested in a given project, e.g. Lombok, which is an optional > tool for Java, everybody is happy: if you get 100, 1.000, 10.000, > 100.000 enthusiasts, your project will have a bright future, and the > rest of the Java users (who are millions) who don't know, don't care or > don't like it will still live happy. > > Things are different if one pretend that 1.000 or 10.000 people make a > decision to change Java that will affect everybody. My personal > experience is that the vast majority of my customers (I'm talking of > several firms from small to large) don't give a bit for closures (just > to make an example), don't feel they need it, don't feel they like it > and are neutral or negative with them. My personal experience with > forums or mailing lists of various human activities (not necessarily > technological ones) is that they might have thousands of subscribers, > while the traffic is lead by tens of them. Thus, any discussion made by > those tens of persons can't be deemed of representative of the whole > community. > > *** I don't think that neither blogs or mailing lists are true > representative of the reality out there (technological, political, or > what else). *** They only make more noise, but the standard rules for > democracy are still "one head, one vote", so they only count for > themselves. That's why, for instance, to elect a government blogs and > such can be thought as influential, but in the end you do count any > single vote. > > As I said, this has to do with how do you define community: people who > attend blogs, mailing lists and conferences, or the whole set of users. > Of course I reckon that there is a problem with the latter, as we can't > measure it. Neither I'm pretending that Sun was right in not accepting > BGGA because they allegedly know the wishes or the whole set of users. > Neither I can, of course, pretend that I or my customers are > representative of the majority. But even if we accept the former > definition of community, I think that before declaring that the > community wants something, we need some sort of poll that, while > shouldn't necessarily be as formal and controlled like an election poll, > must be decently structured. For instance, Java.Net polls are not good, > figure out if I think that generically quoting bloggers' enthusiasm is good. > > Given that, I'm not proposing to set up such a poll, because I don't > know how to set it up (and nobody says that a technical community is a > "democracy" in the strict sense - in fact, it isn't). A good half+ of my > customers don't even know or read Java.Net, DZone.com or JavaPosse or > attend a JUG, so I wouldn't be able to say how to reach and ask to > everybody. I'm only saying that in this situation, I'm all but > scandalized if Sun takes decisions such as not putting BGGA or other > stuff in the JDK. They can be
[The Java Posse] Re: #277: Not a view from an ivory tower
On Sep 3, 5:22 am, Joshua Marinacci wrote: > Thanks Joe. I appreciate this response. Any chance we can get a blog > on it to spread around? > On Sep 2, 2009, at 8:44 PM, jddarcy wrote: I've posted a lightly edited copy of my post at http://blogs.sun.com/darcy/entry/javaposse_277_ivory_tower --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: #277: Not a view from an ivory tower
1) Works really well for a while. Hard to not care though. 2) Doesn't do much more than make you look like a trouble maker. 3) The grass is always greener somewhere else. Believe me, it is because of the manure. 4) Very commendable but hard to pay the bills. Great if you can make it fit the needs of your current job. Otherwise it ends up becoming a second job. 5) Start a company and make all the decisions. Just need to find something people will give you money for. Best of both worlds but very difficult to pull off. On Thu, Sep 3, 2009 at 5:48 PM, Casper Bang wrote: > > Funny enough, I just submitted such a poll to java.net since there are > certainly more average developers following it, than there are > tracking the coin mailing-list. Personally I don't think language > design should be a democratic endeavor exactly for the reasons > outlined by Joe and Alex, things goes just a little bit deeper than > most can fathom. What you *can* find out by asking the community > however, is what they struggle with daily and what would excite them. > And I should add that my definition of a community does not cover the > JCP members who are not really interested in Java per se, but much > more interested in profiting on their latest SOA vendor lock-in. > > So as an engineer interested in improving my day-to-day environment I > have only a few options 1) become a cubicle robot and not care about > this stuff at all, 2) be a loudmouth and try to push what I feel is > good taste in programming, 3) find another job where I can choose a > stack that makes me feel productive and passionate again or 4) help in > undermining official Java and put my faith in the grassroots of the > community i.e. Lombok. Given the relatively mute blogosphere > surrounding JDK7, I am probably not the only one contemplating these > options. > > /Casper > > > On 3 Sep., 22:47, Fabrizio Giudici > wrote: > > Reinier Zwitserloot wrote: > > > I'd also like to state my support for Jess Holle's very astute > > > observation that the first serious attempt to build a fully specced, > > > fully prototyped proposal (BGGA) got a rather lukewarm response from > > > sun. The BGGA proposal didn't just have an excellent spec and > > > prototype behind it, it has received more community support than any > > > proposal I've _ever_ seen in the history of java. All that, and sun > > > still doesn't care? > > > > I know I'm going to raise a can of worms :-) but there are some points > > that have to be addressed here. It all depends by what "community" > > means, but the fact that there are blogs praising a certain feature, or > > even a lot of messages in a mailing list doesn't prove that the majority > > of the "community" wants that. To be more precise, if you have a lot of > > people interested in a given project, e.g. Lombok, which is an optional > > tool for Java, everybody is happy: if you get 100, 1.000, 10.000, > > 100.000 enthusiasts, your project will have a bright future, and the > > rest of the Java users (who are millions) who don't know, don't care or > > don't like it will still live happy. > > > > Things are different if one pretend that 1.000 or 10.000 people make a > > decision to change Java that will affect everybody. My personal > > experience is that the vast majority of my customers (I'm talking of > > several firms from small to large) don't give a bit for closures (just > > to make an example), don't feel they need it, don't feel they like it > > and are neutral or negative with them. My personal experience with > > forums or mailing lists of various human activities (not necessarily > > technological ones) is that they might have thousands of subscribers, > > while the traffic is lead by tens of them. Thus, any discussion made by > > those tens of persons can't be deemed of representative of the whole > > community. > > > > *** I don't think that neither blogs or mailing lists are true > > representative of the reality out there (technological, political, or > > what else). *** They only make more noise, but the standard rules for > > democracy are still "one head, one vote", so they only count for > > themselves. That's why, for instance, to elect a government blogs and > > such can be thought as influential, but in the end you do count any > > single vote. > > > > As I said, this has to do with how do you define community: people who > > attend blogs, mailing lists and conferences, or the whole set of users. > > Of course I reckon that there is a problem with the latter, as we can't > > measure it. Neither I'm pretending that Sun was right in not accepting > > BGGA because they allegedly know the wishes or the whole set of users. > > Neither I can, of course, pretend that I or my customers are > > representative of the majority. But even if we accept the former > > definition of community, I think that before declaring that the > > community wants something, we need some sort of poll that, while > > shouldn't necessarily be as fo
[The Java Posse] Wicket design question for Dick (or is one of you guys knows it you can answer me too :)
Hi Guys. I was there during the Roundup '07 and had a blast. You may remember me as the pilot. Unfortunately, I got laid off and now programming again. We are evailuating web frameworks (ugh) and I know from the podcast that Dick uses Wicket. I've noticed that there are a lot of duplication between wicket .html and .java files, i.e. forms are 'created' in both html and java. This seems to me a bad duplication effort, and introduces lots of room for errors. What do you think about this? Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Quicksort large amount of data
Is it realistic to use HashSet to determine if a large amount of string data (2 000 000 strings of length 20) is composed of unique entry ? If not, is it realistic, in a more general way, to quicksort this large amount of string data in memory (not using an extern or file quicksort) ? Thank you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: #277: Not a view from an ivory tower
Casper Bang wrote: > Funny enough, I just submitted such a poll to java.net since there are > certainly more average developers following it, than there are > tracking the coin mailing-list. Personally I don't think language > I'm not in the coin mailing-list, so I trust your numbers. Still, looking at the latest 15 polls, the max. number of cast votes is 630. Sounds quite low compared to the number of people using Java. > design should be a democratic endeavor exactly for the reasons > outlined by Joe and Alex, things goes just a little bit deeper than > most can fathom. What you *can* find out by asking the community > I don't think it must be democratic either. Generically speaking, my point on open source projects is that the best governance model is the "benevolent dictatorship". Probably, such a widespread project like Java should go rather with a "benevolent oligarchy", that is to be as open as possible, without pretending to be democratic. The "democratic deficit" is compensated with competition: let the oligarchy make its decision on Java, if the decision is wrong the technology will decline. Amen, it's the natural selection. While I consider almost useless statistics such as Tiobe etc, a strong decline could be easily detected. If people start really thinking that Java-the-language is no more effective for their needs, they'll use something else (Scala, Groovy, Fan, whatever-to-be-invented). Fortunately, we have competition at any level. Eventually, the oligarchy could find the time to compensate a wrong decision and save the technology - after all, that's what happened with EBJ 1/2 - > Spring -> EJB 3. > however, is what they struggle with daily and what would excite them. > And I should add that my definition of a community does not cover the > JCP members who are not really interested in Java per se, but much > more interested in profiting on their latest SOA vendor lock-in. > I'm not interested in judging the JCP members, also because I don't know any. Still, your point about asking what the "community" struggle with and what would excite them can't avoid facing with the problem of defining the community. In my partial view of the community, the part that I can experience, I've already said that almost nobody is interested in what are usually considered the "hot" topics. I don't think any can "proof" his own perspective is the right one. > So as an engineer interested in improving my day-to-day environment I > have only a few options 1) become a cubicle robot and not care about > this stuff at all, 2) be a loudmouth and try to push what I feel is > good taste in programming, 3) find another job where I can choose a > stack that makes me feel productive and passionate again or 4) help in > undermining official Java and put my faith in the grassroots of the > community i.e. Lombok. Given the relatively mute blogosphere > surrounding JDK7, I am probably not the only one contemplating these > options. > But I agree - I don't think we have to shut up. Shutting up is always a bad solution. I myself I can show off a good record of "whines" and complains ;-) especially on some topics (did anybody say "Apple"?). Still, I don't pretend I'm representative of a majority or a minority. Also because we tend to work with customers that share our same sympathies - e.g. I could say that I don't see people around me working with .NET, but certainly I don't infer that .NET is irrelevant or such. -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog fabrizio.giud...@tidalwave.it - mobile: +39 348.150.6941 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Wicket design question for Dick (or is one of you guys knows it you can answer me too :)
Have a look at JSF and you will come fleeing back to Wicket. What Wicked gives you, that other frameworks does not, is the ability to avoid XML and use your existing HTML and Java skills. Also, it's really easy to create your own components and obtain reuse that way, something I have not seen much of elsewhere. Last but not least, Wicket's fluent interfaces are great for exploratory leaning - there's just something nice about having your IDE guide you. This is what Java does quite well. There's also Stripes but whatever you do, stay away from JSF. lol /Casper On 3 Sep., 22:05, Lenny P wrote: > Hi Guys. > > I was there during the Roundup '07 and had a blast. > You may remember me as the pilot. > > Unfortunately, I got laid off and now programming again. > We are evailuating web frameworks (ugh) and I know from the podcast > that Dick uses Wicket. > I've noticed that there are a lot of duplication between wicket .html > and .java files, i.e. > forms are 'created' in both html and java. This seems to me a bad > duplication effort, > and introduces lots of room for errors. What do you think about this? > > Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: #277: Not a view from an ivory tower
On Sep 3, 6:37 am, "Vince O'Sullivan" wrote: > Thanks for your response to criticisms of the lack of significant new > features in Java 7. I was more so responding to the implication that Sun is not seeking input from the broader community (Sun is part of the Java community of course) when Project Coin offered an unprecedented invitation for people "in the trenches" to participate in evolving the Java language. This invitation to participate always came with the implication of participating *in the work* of the language changes, including writing and analyzing the proposals and developing prototypes. The Java Language Specification has been online for over a decade, Sun's Java compiler has been open sourced for several years, and blog entries have been written describing the many tasks that need to be done to add a language feature to the platform. Sun is not preventing anyone from undertaking the work of exploring a language change. Rather, especially with OpenJDK, we have greatly facilitated such explorations. > It is very important to know that there is a > ready line of communication between the people who control a language > and those who use it. > > Having said that, could you answer this question... > > Which of the new features in Java 7 do you think will do most to > address the current flow of talented programmers away from Java and to > alternative languages (such as Scala, groovy, Python, c#, etc.). Any > why? I would expect programmers to choose the best language and platform for their programming task, which may be Java alone, a mixture of Java and some other language, or just some other language. As the Project Coin changes are by design small, they do not fundamentally change the scope of programs that are tractable to write in Java. In contrast, the modularity language work *does* have the potential to meaningfully expand the set of programs writable (and maintainable) in Java. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Quicksort large amount of data
do it and find out :) i dont think the hashing of the collections classes have anything against such high object counts. it might just be a concern of memory. on average, do you expect all 2 million strings to be unique? how often do you expect duplicates? you could do the processing in smaller batches. all even hash codes then all odd ones. but i'd avoid doing anything like that if you can. you're normal Arrays.sort() is pretty good i believe. On Sep 4, 1:14 am, Barney wrote: > Is it realistic to use HashSet to determine if a large amount of > string data (2 000 000 strings of length 20) is composed of unique > entry ? > > If not, is it realistic, in a more general way, to quicksort this > large amount of string data in memory (not using an extern or file > quicksort) ? > > Thank you. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
